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ABSTRACT 


Transaction processing (TP) applications are of use when solving a wide variety 
of data processing problems. Current, commercial TP systems do not possess the ability 
to manage information at multiple security levels with high assurance. Department of 
Defense and Department of Navy Command, Control, Communication, Computers and 
Intelligence (C4) applications handle information over a wide variety of classifications 
and compartments. The existence of TP applications that can securely process 
information of different classifications (with assurance) would save the Department of 
Defense the need to create separate, single level systems to process all necessary 
information. 

A trusted computing base (TCB) and security kernel architecture for supporting 
multi-threaded, queue-driven transaction processing applications in a multilevel secure 
environment has been designed. Intel's Pentium CPU architecture provides hardware with 
two distinct descriptor tables. One is used in the usual way for process isolation while 
the other is used for thread isolation. This allocation, together with an appropriately 
designed scheduling policy, permits us to avoid the full cost of process creation when 
only switching between threads of different security classes in the same process. Where’ 
large numbers of transactions are encountered on transaction queues, this approach has 


benefits over traditional multilevel systems. 
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. INTRODUCTION 


Although many of the traditional transaction processing (TP) systems fulfill a 
variety of commercial needs, there are applications that lend themselves to TP but levy 
the added requirement to provide multilevel security (MLS). Examples might be a 
military command and control (C’) system supporting users at different access classes or 


a central financial clearinghouse simultaneously processing transactions for several 


competing banks. In our notional C’ system, this single TP system receives input in the 


form of positional data from a variety of sources. Although the format of this positional 


data might be the same for different input sources, the classification of the data varies 
based upon the sensitivity of the source. 

As an example, the positional data for a ship which itself broadcasts its location 
might be CONFIDENTIAL (C) whereas the same positional data obtained through some 


‘sensitive intelligence sensor might be classified TOP SECRET (TS). Scenarios such as 


this, where information of the same type has varying classifications based upon source, 
are commonplace in military intelligence and command and control applications. 

We can also see the need for such a system to support users of varying clearances as well. 
For instance, the commander of a small ship might be cleared to view data up to and 
including SECRET (S) whereas the commander of a battle-group might be cleared to 
view data up to and including TS. In atypical C’ system, the output viewed by the users. 
might take the form of a graphical display showing the position of various units. 
Although these various displays might be driven by a shared MLS database, updating this 
database is the responsibility of the TP system. 

This is a classic application for TP systems: small packets or input (positional 
reports) are processed by programs (TP tasks) to produce output (updating a shared MLS 
database.) Traditional high assurance multilevel operating systems are designed to 
support general purpose processing. Users log in and run a series of arbitrary processes 


that are dynamically created and terminated. The scheduler, similar to that in a 








traditional multiprocessing system (Stallings, 1998), is organized to support users at 
different security levels running a variety of tasks. 

Tn contrast, transaction processing systems, once initialized, are more like an 
assembly line or Petri net. The tasks are static and units of work (transactions) flow from 
one task to the next. Transactions are placed on input queues. A transaction processing 
task will work on items from its input queues until the queues are empty and will place 
work on the queues for the next task in the work flow. Rescheduling does not take place 
until the task has nothing to do (Bernstein and Newcomer, 1997). (Note that for now we 
consider queues to be unbounded and do not consider rescheduling caused by 
- encountering a limit on queue size.) In a traditional high assurance multilevel operating 
system, a process switch is required when changing from one security level to another. 

To process transactions on a general purpose high assurance multilevel operating 
system, process switches would be required each time an item at a different security level : 
was encountered on the input queue. This would result in a severe performance penalty 
even though the same task is being performed on each transaction. 

In this thesis, an architecture is presented for a high assurance multilevel security 
system specifically intended to support TP. Chapter II presents some background on the 
problem, the scope of this project and discusses the architecture of a typical commercial 
TP system. Chapter III discusses some alternate ways to create an MLS TP system. 
These alternatives include creating separate, single-level TP systems for each possible 
classification/compartment pair or creating a TP system on top of a current MLS general 
purpose system. Both alternatives are argued to be inadequate. Chapter IV briefly 
introduces the security features of the Intel Pentium microprocessor that will be utilized. 
Chapter V presents the architecture and provides an overview of the modules that 
comprise it. Chapters VI through VIII present the simplified specification for the various 


components of the system. Chapter IX concludes the thesis. 





Il. BACKGROUND 


A. PROBLEM STATEMENT 


The primary reason TP systems are developed independently of general purpose © 
operating systems is performance. Either the response of the system or the throughput 
must be optimized (Bernstein and Newcomer, 1997). This creates a problem when 
dealing with multilevel transactions. In order to maintain assurance against compromise, 
MLS systems must often perform elaborate steps when switching between processes with 
differing classifications. These steps are to ensure that the new process cannot access 
anything that was used by the old process, in accordance with a chosen security policy. 
These steps also require processor time that cannot be used to process transactions, 


creating inefficiency. 


B. SCOPE 


The Intel Pentium series of microprocessors implement some interesting security 
features in hardware. These features (two general purpose descriptor tables and four | 
privilege levels) allow efficient switching between processes while still providing assured 
isolation between the processes. 

This thesis presents a preliminary, general architecture and simplified 
specification for an MLS TP system that exploits these microprocessor features. It does 
not present a complete, implemented system nor a detailed specification appropriate for 
formal assurance arguments. The simplified specification is for the modules, functions, 
databases and interfaces that would comprise the completed system. This specification 
should be viewed as scaffolding upon which future implementation work can be based 


and is subject to change. 





C. TRADITIONAL TRANSACTION PROCESSING 


Although the architecture of a traditional transaction process system has been 
briefly touched upon, a formal introduction is relevant to our architecture. A transaction 
is defined as a unit of input (Bernstein and Newcomer, 1997). Its lifetime runs from 
when it is initially enqueued to the system to when it is finally dequeued and leaves the 
system or.is destroyed. We further define a TP task as the actual TP program executed to 
process a single transaction (unit of input). The transactions are removed from the 
queues and processed by the TP tasks. TP tasks can also add new transactions, or return 
transaction previously removed, to the queues. The nature of the TP tasks or the 
transactions can vary, but the overall structure remains the same. Normally, the function 
performed by a TP task will involve the update of some shared database, but it could just 


as easily result in the generation of a new transaction containing a single value. 


1. Basic TP Architecture 





Figure 2.1: Traditional Transaction Processing Architecture 


In a typical queued TP system (such as Figure 2.1), queues are used as the buffer 
for input and output from the TP tasks. A TP task is run by a TP manager to process a 
transaction or multiple transactions from one or more input queues. Multiple TP tasks 


might be run (in a multiprocessed environment), all taking transactions from input 








queues. The TP tasks write their results (if any) as new transactions which are enqueued 
on output queues. | 

The TP tasks access the transactions by performing operations on the queues. The 
dequeue operation is used to get a transaction from a queue. The transaction is not 
immediately deleted from the queue but instead is saved in a holding area pending 
notification from the task that the transaction has committed. Once the task has 
completed processing the transaction, it may perform an enqueue operation on another 
queue to pass along its results in the form of a new transaction. Finally, a commit 
operation indicates that the results of processing the transaction have been durably 
recorded and the transaction can be permanently deleted from the holding area of the 
input queue. | 

A TP system might consist of several queues with different types of TP tasks 
being run to process the inputs. The system might consist of multiple copies of a single 
TP task (if it only performs one function) or several hundred different types of TP tasks 
to process a wide variety of input types. Additionally, there could be a single input queue 
which holds all inputs of all types or perhaps several different input queues each holding 
a specific type of input. The same might apply to the output queues. Again, the central 
working of the TP system remains unchanged: 1) a unit of input is received and placed on 
an input queue, 2) a TP task is run to process a single unit or multiple units of input (from 
queues), and 3) the TP task completes and enqueues results (in the form of new | 
transactions) on output queues or updates some shared database. This is the paradigm we 
will use for our design. 

TP systems also usually implement logging. Logging of transactions is necessary 
for graceful recovery with a minimum loss of transactions. Should the system fail while 
several TP tasks are in the midst of processing transactions, the transaction that were 
being processed must not be lost when the system recovers. Although this is a 


requirement for implemented TP systems, it is not included in the architecture presented, 


but would need to be part of any final implementation. 














TP systems also need to allow variable workflow. For example, consider the set 
of TP tasks and queues in Figure 2.2. After TP task B has completed processing a 
transaction it may enqueue a new transaction on both queues for TP tasks C and D. The 
TP system’s queue management needs to ensure such dynamic workflow is allowed. The 
system becomes much more complex when we consider that the TP tasks might be at 
different sensitivity levels. A sensitivity level is a reflection of the damage that would 
result should the information be divulged to parties who are not cleared to receive it. 
These sensitivity levels are typically part of a hierarchical policy, such as the Bell and 
LaPadula model (Bell and LaPadula, 1976), so a task with a high sensitivity level can 
read all information at its level and below but is prohibited from writing information to a 
lower level. Sensitivity levels are analogous to military classifications. In Figure 2.2, if 
TP tasks A and C were at a high sensitivity level and TP tasks B and D were at a low - 
sensitivity level, then TP task A would not be allowed to enqueue (write) a new 


transaction for TP task D (this would be a violation of the security policy.) 





Transaction 


Queue 


a sre 
wig 





Figure 2.2: Variable Workflow 





2. TP Requirements 


There are also four critical properties normally associated with transactions (and 
which must be maintained by the TP system). These properties are atomicity, 
consistency, isolation and durability (ACID) (Bernstein and Newcomer, 1997). 

A transaction is atomic in the sense that it either completes fully or does nothing 
at all, there is no notion of partial work. The TP system must have a mechanism in place 
to ensure that the results of the TP task do not take effect until the task successfully 
completes. A successful completion of a transaction is called commit and the failure of a 
transaction is called abort. 

| Consistency in TP applications normally applies to any shared database accessed 
by multiple tasks. A database that is consistent prior to the running of a transaction 
should be consistent following completion of the transaction whether successful or not. 
Database consistency normally refers to entity and referential integrity and possibly the 
maintenance of some invariant. | 

The isolation ofa TP application refers to the serializability of transactions. The | 
transaction runs as if it were running alone with no other transactions. That is, the 
transaction should not be affected by the concurrent running of any other transaction or 
any other system activity that might occur during its execution. 

Durability means the results of a successful transaction are permanently stored on 
a medium that will survive the failure of the TP system. Typically this refers to writing 
the results of processing the transaction onto some type of disk storage medium (audit 
log). 

Additionally, when a transaction updates data on several distributed systems or in 
a client/server environment, the two-phase commit protocol might be used to ensure 
successful completion of the transaction updates on both systems (Bernstein and 
Newcomer, 1997). The details of the two-phase commit protocol are not addressed here 


‘ 


and are not central to our design. 





The final note we will make about TP systems is that performance is an issue. 
Typically, a system will be designed for maximum throughput, that is, designed to 
complete the maximum number of transactions possible in a given amount of time. This 
is the main reason TP systems are designed as special purpose systems as opposed to 
modifying some other type of system to support TP. For example, a typical interactive 
timesharing system could be modified to support TP, but since it was not optimized for 
such an application, throughput is likely to suffer compared to a system designed 
exclusively for TP. The main reason for this inefficiency is the overhead normally 
associated with process switches in typical interactive timesharing systems (Stallings, 
1998). A process switch will typically involve the saving of all registers and the switch 
of all descriptor tables. On the Intel Pentium series of microprocessors switching the 
Global Descriptor Table (GDT) is a time consuming process. Switching between two TP 
tasks might not require this full context switch and thus might be accomplished much 


faster with a smaller context switch. 


3. MLS Requirements 

The MLS TP architecture presented imposes additional requirements not found in 
typical TP systems. The system should enforce a mandatory security policy providing 
MLS. This could be a mandatory confidentiality policy (Bell and LaPadula, 1976), a 
mandatory integrity policy (Biba, 1977), or both. When a transaction of a given 
sensitivity level is executing, the system should ensure it can read and write objects only 
in accordance with the mandatory policy. 

Performance is an explicit requirement for the system as well. It should be 
capable of switching between sensitivity levels as rapidly as possible, consistent with 


properly enforcing the policy. 





Il. ALTERNATIVE SOLUTIONS 


Alternate approaches to creating an MLS TP system are examined and rejected. 
The first is the approach traditionally taken; to create wholly separate subsystems which 
process information at a single level for users cleared to that level. The second approach 


uses already developed MLS timesharing systems to implement MLS TP. 


A. SEPARATE SUBSYSTEMS 
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Figure 3.1: A MLS TP System Composed of Separate Single Level TP Systems 


The approach taken by most designers to date has been to create almost 
completely separate systems, each of which processes information of a single level for 
users cleared to that level as depicted in Figure 3.1. Each subsystem then operates in 
dedicated mode (DoD, 1985) without the need for any elaborate internal security features. 

| An MLS TP system is created by building several separate TP systems, each TP | 
system processes information of a specific sensitivity level. Using the initial C” example, 


one system would be created for every level of user that must be supported. For example, 
if users cleared to CONFIDENTIAL (C), SECRET (S) and TOP SECRET (T'S) must be 











supported, three separate TP systems must be created. Each system would have its own 
database. Sensor information at lower levels would be forwarded to higher systems to 
ensure high level users received all information they are cleared for. For example, a C 
report would be input, not only to the C TP system, but also to the S and TS TP systems. 
Thus a TS user would see C, S and TS positional data (as he should). | 

The advantage of such a TP system of systems is clear. Since each TP system is 
operating in dedicated mode; there is no need for security mechanisms within each 
system. As such, commercial of-the-shelf (COTS) TP and database management systems 
(DBMS) could be used. A high assurance system, such as the Naval Research 
Laboratory (NRL) pump (Kang, Froscher, and Moskowitz, 1997), is required to push 
information from the lower sensitivity levels to higher ones. These products have already 
been developed and tested and are readily available. The fact that most of these products 
do not provide any security assurance is of little concern since all users who will access 
them are cleared to see all information contained within them. | 

The disadvantage of such a system lies in its inefficiency. For example, looking 
at Figure 3.1, U data is processed identically three separate times by the systems at each | 
level. This needlessly wastes processing power. Another serious drawback to such a 
system iS the triple storage requirements. Assuming U data is most prevalent in the 
system, the requirement to store the U data and results in three separate places is a 
significant storage burden. 

Another disadvantage to such a system lies in its inability to process a wide 
variety of data. If we have the need to separate not just classifications but also several _ 
compartments, we can see that the number of separate systems needed quickly grows. 
When dealing with information and users cleared to several classifications with several 
compartments, the number of needed systems to ensure separation becomes prohibitive. 
Also, since all the systems are separate, the TP goal of consistency might be difficult to 


achieve. Since the C system cannot control when the S system performs its updates (and 
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vice-versa), a C user and an S user, both viewing C data, might not be looking at the 
same thing. 

Finally, users at high sensitivity levels are unable to distinguish between low and 
high information. They must treat all information as high since, with no underlying 
assured mechanism to associated labels with information, no labels can be trusted. 
Downgrading would be difficult, if not impossible. This same problem makes it possible 
for low information to foul the high system. For instance, in intelligence systems, high 
information might be implicitly considered more reliable due to the sources. When low 
and high information are mixed together in a single system with untrusted or no labels, 
such reliability judgements are no longer possible. 

Although such a system leverages COTS products to solve the problem, it is — 
unnecessarily inefficient and fails when required to handle a wide variety of data and user 


classifications and compartments. 
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B. MLS TIMESHARING SYSTEM 
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Figure 3.2: An MLS TP System Implemented On Top of a General Purpose MLS System 


The second alternative considered, but rejected, is placing a TP system on top of 
an already developed and accredited MLS timesharing system (depicted in Figure 3.2). 
In such a system, a single TP task would run as a separate process. The system would 
support TP tasks of differing levels by creating the required number of processes. 
Using the system pictured in Figure 3.2 as an example, when a C input 1s received the 
system would switch to the C process, within which the C TP task would perform its 
function. If an S input were received next, the system would switch from the C process 
to the S process, within which the S$ TP task would perform its functions. Such switches 
from process to process would continue to handle the stream of incoming transactions. 

This scheme has advantages not found in the scheme using separate systems. 
First, we again leverage already developed products (the trusted MLS timesharing 


systems). Additionally, since all processing is done on a single system we avoid the 
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inefficiencies and waste of using multiple, separate systems. We also do not have a - 
problem handling a wide variety of data and user access classes (classification and 
compartment) since it only means the creation of additional processes, not additional 
separate systems. We also gain consistency using this alternative. Since all users are 
viewing the same U data, there can be no inconsistency between and S and U user’s view 
of U data. Additionally, using this scheme, we have labels that can be trusted. | 
The primary reason we reject this scheme is that the MLS timesharing systems are 
not designed for TP. The switches between processes of differing levels might be 
invoked often. Since TP processes of different sensitivity levels execute in different 
processes, switches between processes occur whenever transactions of different 
sensitivity levels must be processed. Switches between processes in a general purpose 
MLS system requires at least as much time as process switches in single-level general 
purpose systems, often more. Access level context switches are costly in time when 
performed on an MLS timesharing system. We did not encounter this problem when 
using separate systems since each system runs in dedicated mode without worrying about 
security, there is no need for any context switches. So, although we have removed the 
unnecessary redundancy we suffer a significant, unacceptable performance penalty when 


moving between TP tasks of differing access classes. 
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IV. PROCESSOR INTRODUCTION 


The MLS TP architecture presented is targeted toward the Intel Pentium series of 
microprocessors. This series of processors implement descriptor based segmented 
memory and multiple privilege levels. These architectural features provide a good 
foundation for an MLS operating system. 

The Pentium series microprocessors provide two modes of operation; real and protected 
mode. Real mode is provided for backward compatibility and does not provide any of the 
memory protection required for a multitasking system, much less for an MLS operating 
| systems. Protected mode, however, provides hardware enforcement of memory accesses 

based upon privilege levels, available descriptors and descriptor attributes. Protected 


mode is the target of the architecture. 


A. PRIVILEGE LEVEL STRUCTURE 


Most secure 


Least secure 


Applications 





Figure 4.1: Pentium Privilege Level Structure 


The Intel microprocessors use a four privilege level structure (Figure 4.1) 


numbered 0 through 3 (Intel, 1997). Privilege level 0 is the most privileged and privilege 
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level 3 is the least privileged. As depicted in Figure 4.2, a process running in a given 
privilege level has access to segments with descriptors at its level and above (less 
privileged.) 

Access to any function in a more privileged level is only allowed through a gate 
(Figure 4.3). The gate provides entry points to the more privileged levels. The gate thus 
ensures that access to privileged functions by non-privileged subjects is strictly 


controlled. 


A Data 
1 Code (programs) 
——> Legal access 


is > Illegal access 





Figure 4.2: Access Between Rings 
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Figure 4.3: Call Paths Through Gates 


Through the use of gates, a few functions can be carefully exported from more 


privileged to less privileged levels. The gates can be designed to call routines that 


perform complex validation of arguments to ensure that untrusted tasks are not trying to 


pass invalid arguments to a trusted routine. 
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B. DESCRIPTOR TABLES 


4GB Memory 


Selector] [_Offset _| 





Offset from start 
of segment 
Segment base address 
Virtual address 
translation 
0 


Figure 4.4: Address Translation 


The Intel Pentium microprocessor architecture also provides two general-purpose 
descriptor tables. A global descriptor table (GDT) and a local descriptor table (LDT). As 
seen in Figure 4.4, any access to memory must be via a selector that references an entry 
in either the GDT or LDT. The entry in the table would be the descriptor, which provides 
a description of the segment, including its physical address in memory. The physical 
base address of the segment in memory is used with the offset to find the linear address 
referenced. The descriptors have privilege levels associated with them as well, this 
allows the processor to disallow attempts by less privileged subjects to access more 
privileged segments. Thus, for a process to access memory, the descriptor describing the 
memory segment must be loaded into a descriptor table (either the LDT or GDT) and the 
descriptor must be of the same or lesser privileged level. This access check is performed 


in hardware making the protection mechanism very efficient. 
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V. ARCHITECTURE 


The goal of this work is to design a TP system which provides the protection of 
using an MLS timesharing system while avoiding the heavy performance penalty 
imposed by such systems. Realizing that a TP system might be required to process a 
variety of transaction types, each of which might have a variety of access classes, a three- 


tier architecture has been devised, pictured in Figure 5.1. 
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Figure 5.1: MLS TP Architecture 


‘At the core of the system is the security kernel. The kernel is primarily 
responsible for all mernory management functions, all process management and 
providing eventcounts for process synchronization. 

The middle tier of the system contains the multilevel queue manager and the task 
manager. The multilevel queue manager holds the transactions. The MLS queue 
manager can handle several queues through which the transactions flow while moving 
throtgh the system. The queue manager supports operations to create and delete MLS 


queues as well as to enqueue, dequeue and get work from an MLS queue. 
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A task manager runs within each process and controls the various single level TP 
tasks. These TP tasks are the elements within the system that actually perform all 
processing of the transactions. The task manager will schedule TP tasks, mediate 
memory management requests to the kernel and mediate queue requests. 

Incoming transactions of a given type would be enqueued on the appropriate MLS queue 
by some trusted input processor. The tasks are the outer layer of the system and are 
single level entities which process a given transaction type of a given classification. The 
task manager will get work from the appropriate MLS queues and schedule the TP task of 
the matching access class to handle the transactions. The access class of the transaction 
returned by the MLS queue manager dictates which TP task will run next. When a task 
manager attempts to retrieve a transaction from an empty MLS queue it blocks on an 
event count and precipitates a process switch. | 

By delegating the management of a few similar tasks (identical save that each task 
only processes transaction of a given sensitivity level) within the process to the task 
manager, we hope to create an efficient mechanism for switching between the tasks, 
keeping kernel intervention to a minimum. Kernel intervention is only required when 
switching between processes (or transactions of different types.) | 

The final tier of the system contains the actual TP tasks which process the 
transactions. The tasks in this level are untrusted and are the objects that perform the 


work. 
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A. LAYERING AND DEPENDENCIES 


Privilege Level 3 
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Figure 5.2 shows the system layering and the trust boundary. The kernel resides 


Figure 5.2: System Layering 


in privilege level 0 (most privileged). The queue manager and task manager reside in 
privilege level 1. The untrusted TP tasks reside in privilege level 3. Privilege level 2 is 
not used in the current architecture and is available for future use. The kernel, queue 
manager and task manager are trusted. They have the ability to violate the chosen 
security policy but are trusted not to due to strict control over implementation. The TP 
tasks are not trusted and may be coded by anyone using whatever controls they choose. 


The TP tasks cannot violate the chosen security policy even if they try. This is not to say 
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that a poorly written or malicious TP task cannot cause the system to crash, it can. 
However, there is no way that any unauthorized information flows can occur to, from or 
between the TP tasks. | 

The layering pictured in Figure 5.2 is strict. Functions within a module only call 
functions in within themselves or within modules in a lower layer. In this avoid circular 


dependencies within the code. 


B. SECURITY KERNEL 


The security kernel consists of several distinct subsystems. There is a process 
manager, which is responsible for creating, scheduling and destroying processes. There 
is amemory manager, which manages the various local descriptor table (LDT) images 
(used by the individual tasks within each process space), the global descriptor table 
(GDT), memory allocation and deallocation, and adding or removing segments from any 
of the descriptor tables. Finally, there is a kernel event manager, which manages 
eventcounts used by the processes and the MLS queues. These eventcounts are used for 


synchronization by all modules in the system. 


1. ‘Process Manager 


The process manager, as the name implies, manages the processes, which equate 
to different transaction types. The process manager implements several operations to 
manage processes. | 

e Create a process 
e Switch from the active process to another process 
e Destroy a process | 
e Change a process status 
e Return an identifier for the current process 
- Associated with each process is a global descriptor table (GDT) image. These 


GDT entries are where each process stores the code and data the task manager needs to 
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perform its functions. Upon a process switch, this GDT image is switched to reflect the 
new processes’ entries. The process manager also performs scheduling of processes. 
The process manager is supported by one data structure: 
e Process table — holds the process information (including GDT image) needed to 
manage processes 
The process table allows the kernel to map a given process to its GDT image. A 
process switch also results in a switch of the contents of the process portion of the 


.GDT. Processes can be in one of three states: ready, running or blocked on an event. 


2. Memory Manager 


All code and data used by a task is contained wholly in the LDT and all code and 
data used by the kernel, the MLS queues and the processes are contained wholly in the 
GDT. As such, a task switch involves-only an LDT switch. The memory manager can be 
viewed as being logically divided into two distinct subsystems; one which manages the 
LDT and one which manages the GDT. Whenever a new task is created, a new LDT 
image is created to hold the descriptors for its address space. Associated with each LDT 
Image is an identifier which 

a) LDT Manager 
The LDT component maintains a database of LDT images. Each of these 
LDT images is associated with a given TP task. However, the mapping between a given 
LDT images and a specific task is not maintained by the kernel, but instead is maintained 
by the Task Managers. The LDT component provides functions to: 
e Create anew LDT image 
e Destroy an LDT image 
e Addasegment to an LDT image 
e Remove a segment from an LDT image 


e Make a given LDT image the current LDT 
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When a task requests the addition of an item to its LDT, the request is 
brokered by the Task Manager. The Task Manager would add access class information 
and the specific LDT image identifier to the request prior to forwarding it to the kernel. 
The LDT component would check the security attributes of the segment being added to 
ensure they are consistent with the arguments of the request. If the request operation 
would not violate the security policy it is carried out. If the request operation would 
violate the security policy it is rejected. 

When a task manager creates a new task, a new LDT image 1s created 
which the Task Manager would then associate with that task 

The LDT component is supported by one data structure: 
e LDT Database — keeps track of LDT images and their physical location in 
memory 

b) GDT Manager 

The GDT component of the Memory Manager is responsible for managing 
the GDT as well as allocating and deallocating memory. The specific functions it 
provides include: | | 

e Create anew GDT image 

e Destroy a GDT image 

e Adda segment to a GDT image 

e Remove a segment from a GDT image 
e Switch GDT segments ~ 

e Allocate memory 

e Deallocate memory 

Associated with each process is a GDT image. On a process switch the 
process portion of the GDT must be saved to the currently running process' GDT image 
storage segment while the GDT image of the new process must be restored to the process 


portion of the GDT. | 
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The call to switch a GDT segment comes from the Process Manages which 
actually performs the context switch. | 
The GDT manager is supported by one data structure: 
° GDT Database — keeps track of the GDT images for the various processes 
c) KST Manager a 
The KST manager is responsible for those functions that manipulate the 
Known Segment Table (KST). These functions include: 
e Allocating a segment and adding it to the KST 
e Deallocating a segment and removing it from the KST 
e- Returning the attributes associated with a segment 
The KST manager is responsible for one data structure: 
e KST-—the Known Segment Table, keeps track of all segments currently in the 


system and their attributes (security label, descriptors, etc.) 


3. Kernel Event Manager 
The process event manager provides eventcounts for use by the processes and the 
MLS queues. The event manager provides the following functions: 
Create an eventcount | 
e Destroy an eventcount 
e Wait on an eventcount 
e Advance an eventcount 
e Geta ticket 
The MLS queues use kernel eventcounts to keep track of the number of items in a 
queue. A call to get work from an empty queue becomes a wait call on a kernel 
eventcount and leads to a process change. When new items are added to this queue, the 
| associated kernel eventcount is advanced which moves the blocked process from the 
blocked process list to the ready process list making it eligible to be scheduled. Process 


scheduling is determined by the transaction flow through the MLS queues. 
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The kernel event manager is supported by one data structure: 
e KED-the kernel event database, tracks the values of the various eventcounts and 


sequencers 


C. PROCESS QUEUE MANAGER 


The Process Queue Manager is the entity of the system which managers the MLS 
queues. It is layered between the process (Task Manager) and the kernel. The Process 
Queue Manager provides functions which allow processes to: 

e Create an MLS queue 

e Destroy an MLS queue 

° Enqueue an item on an MLS queue 

e Dequeue an item from an MLS queue 

e Get and item from an MLS queue (whithout dequeuing it) 

Initial input transactions are added to the system and are put on the MLS queues 
(usually by type) by some trusted input process. This process would enqueue an 
incoming transaction on the MLS queue associated with the process that handles 
| transactions of that type. The transactions are of varying access classes. The Task 
Manager maintains single level tasks which process the transactions from the MLS queue 
(based on access class). 

The Task Manager would make a ‘get work’ request to the MLS queue manager 
while providing a preferred access class. The Task Manager seeks to keep running the 
same TP task (at a specified access class) as long as work exists for that task to process. 
This minimizes task switches and provides maximum throughput of transaction through 
the system. The Process Queue Manager will return an item at the requested access class 
or an item at a different access class if: (1) there were no items at the requested access 
class or (2) there is a transaction with a higher priority than the next transaction of the 


requested access class. The access class of the item returned by the Process Queue 
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Manager determines whether the current task remains running or whether a new task will 
have to be scheduled. | | 

A call to ‘get work’ from an empty queue would block (being translated into a 
wait call on a kernel eventcount). The process of the calling Task Manager would thus 
be blocked and a Hew process scheduled by the kernel. When the blocked process has an 
item enqueued to it (which also involves a call to advance the appropriate eventcount), 
the process would be moved to the ready list and could be scheduled to run. 
Ali the functions of process queue manager are exported to the task manager. 

The process queue manager is supported by one data structure: 

e PQD — the process queue database, keeps track of information about the various 


MLS queues 


D. TASK MANAGER 


Each process contains a Task Manager which manages the single level TP tasks 
for each transaction type. The task manager creates, schedules and destroys the 
individual tasks. | 

The Task Manager is responsible for managing the single level tasks within each 
process space. The operations supported by the task manager include: 

e Create a new single level task 
e Switch from the current single level task to another 
e Destroy a single level task : 

The Task Manager implements scheduling of single level tasks within its process 
space. Besides directly managing the TP tasks, the Task Manager also serves as an 
intermediary for task access to kernel memory management functions (add/remove from 
LDT). | 
When a tasks attempts to add or remove a segment from its LDT image, the Task 


Manager passes the request on to the kernel after adding the access class of the requesting 
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task and the identifier for its LDT image (both of which are kept track of by the Task 
| Manseer. | 
Additionally, the Task Manager interfaces with the Process Queue Manager to 
retrieve and insert items into MLS queues on behalf of the tasks. When a task makes a 
request for a new transaction, the Task Manager makes a call to ‘get work’ of that 
appropriate access class from the appropriate queue. If the returned item is of the 
requested access class, the Task Manager returns it to the TP task which continues to run 
(no task switch). If the Process Queue Manager should return an item of a differing 
access Class, the Task Manager would suspend the current task and begin running the task 
of the access classs associated with the returned transaction. An attempt to “get work’ 
from an empty queué would block and not return until their were items available in the 
queue. 
The Task Manager is supported by one data structure: . 
e TD -the task database, tracks the current single level tasks being managed by the 


task manager 


E. TASKS 


The tasks are in the outermost layer of the architecture and are the untrusted 
applications. It is the tasks that actually do whatever work is required by the transactions. 
Each task is at a single level and might coexist with copies of itself at different sensitivity 
levels within the same process space. However, through task manager manipulation of 
the LDT images, each task has it’s own distinct address space (perhaps sharing a read- 
only code segment.) Since the task manager sets up an LDT image for a task when it is 
created, a task switch requires simply changing the current LDT. 

Our chosen benchmark of performance will be transaction throughput. Our 
scheduling policy will entail completely processing all entries in a given queue before 
moving on to the next queue. So, a process will continue to execute so long as 


transactions remain in the MLS queue it is waiting on. Likewise, within the process, a 
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task continues to execute so long as transactions of the appropriate access class remain in 
the MLS queue its controlling process is waiting. In this manner, we minimize the 
number of task switches within a process and minimize the number of processes switches 
within the kernel. Each task will have a separate stack and a task switch will also involve 
a stack switch. By minimizing the frequency of process switches (which require the most 
time to accomplish) with our scheduling policy, and by making the task switches as quick 
as possible, we believe we can achieve better performance than would be possible 


implementing ; a ‘TP system on top of a pre-existing MLS timesharing system. 


F. INPUT/OUTPUT 


We have not specifically addressed any input/output functionality required by the 
tasks besides the primitive enqueue, get_work and dequeue. In a real world application, 
the tasks might enqueue transactions to an MLS database. These transactions instruct the 
database to perform updates. Therefore, updating a database entails writing to the queue 
that services it. | 

Traditional block and character input/output and device support would also be - 
useful additions to the system. Devices might be handled using the queues already in the 
system. Writing to a device would be abstracted to writing to the MLS queue associated 
with the device. Likewise, reading from a device would be equivalent to getting work 


from the MLS queue associated with the device. 


G. DISTRIBUTED SCHEDULING 


The system will support distributed scheduling and management. The tasks are 
managed almost wholly by the task manager which is distinct and separate from the 
kernel. When a task attempts to get_work from a queue which contains no items of the 
requested access class, it is blocked (using an eventcount) and another task within the 
same process space is scheduled (via a quick LDT switch). When all transactions within 


a given MLS queue are removed, the Task Manager’s attempt to get_ work would result 
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in a wait call on a kernel eventcount. The kernel would then schedule another process 


that did have work. 
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VI. KERNEL SPECIFICATION 


The following sections contain the specification for the secure kernel, which 
controls the system memory, the management of the various processes and the kernel 
eventcounts. If consists of three components: . 

e Memory Manager (MM) 
e Process Manager (PM) 
e Kernel Event Manager (KEM) 


A. MEMORY MANAGER (MM) 


The memory manager is responsible for managing the GDT and LDT. 


1. LDT Manager 
The LDT component encapsulates those functions associated with management of 
the several LDT images, one associated with every task. It can be viewed as being 
divided into two parts, one that manages the database of LDT images and one that 
manages the LDT images themselves. The part that manages the LDT database provides 
functions to: | 
_ e@ Initialize the LDT database 

e Create anew LDT image 

e Switch to a specified LDT image 

e Destroy a specified LDT image 
The part of the LDT manager that manages the individual LDT images provides 
functions to: | | 

e Initialize an LDT image 

e Adda segment to a specified LDT image 


e Removes a segment from a specified LDT image 


31 





a) LDT Manager Constants 

a. LDT_ DATABASE SIZE - the size of the LDT database, this is maximum number of 
LDT images the system can manager at one time 

b. LDT_ DATABASE MIN ENTRY -— the minimum value that can be used to index the 
LDT database | 

C. LDT SIZE — this is the size of the LDT itself, in the Pentium architecture this is 
8,120 descriptors (Intel, 1997). 

d. LDT_ SEGMENT SIZE — the size (in bytes) of the LDT 

e. END OF LIST — used to mark the end of the list of free database entries\ 


b) LDT Manager Databases 
a. LDT Database 


Each LDT entry stores information about one LDT image 


struct LDT Entry Struct { 
selector: Selector; // selector into the GDT for LDT image segment 
segment: Segment; // segment id for LDT image 
free: Boolean; // is this database entry in use? 
first_free: LDT_Entry; | // the first free item in the LDT 
next: LDT_Database Entry; // used to chain free entries together 


i 


The LDT database is an array of LDT entries. The indices into the LDT database array 
are the LDT identifiers. 


struct LDT_Entry_Struct LDT_Database[LDT_DATABASE._ SIZE]; 
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c) LDT Manager Global Variables 
a. Free LDT Entry : LDT_Database_ Entry — The first free LDT entry in the LDT 
database, this entry points to the next free entry and so on. The last free entry would 


contain an END_OF_LIST. 
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ad) LDT Manager System Calls 
a. ldt_init_ldt_database 
Procedure Idt_init_Idt_database() 
Purpose: This functions initializes the entries of the LDT database 
Inputs: None. 
Outputs: None. 


Processing: 


// cycle through all LDT database entries 

For index = LDT_DATABASE MIN ENTRY to LDT_ DATABASE ‘SIZE 

| 
// null all memory pointers 
LDT_Database[index].selector = NULL; 
LDT_Database[index].segment = NULL; 
// mark all entries as free 
LDT_Database[index].free = TRUE: 
// all entries are part of the free list 
LDT_Database[index].next = index + 1; 


} 


// the last entry is the end of the free list 








LDT_Database[index].next = END OF LIST; 

// the first free database slot is the first slot 
Free_LDT_Entry = LDT_DATABASE MIN ENTRY; 
// set return code and return 

return_code = SUCCEEDED; 


return return_code; 


} 


_ Effects: 
e After completion, all entries in the LDT database are free, and all segment and 


descriptor pointers are null. — 
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b. 





Idt_create_Idt 


Fuction: Idt_create_Idt(Idt_access_ class: Access_Class_Type, Idt_id: 
LDT_Database_Entry): Sucess Code_Type 


Purpose: This call creates a new LDT image at a specified access class. The process 


_1s returned a index into the LDT database at the position where the entry for the new 


LDT image was placed. 


Inputs: — 

e Idt_access_ class : Access Class Type — The access class of the new LDT image. 
This value is provided by the task manager and corresponds to the access class of 
the associated task. This access class must be within the range allowed for the 


calling process. 


Outputs: | 
e ldt_id: LDT_Entry — an index into the LDT database where the new LDT image 
was stored. | 
e Success _Code — indicates the status of the operation. Possible values include: 
- SUCCEEDED -— The operation completed successfully 
- LDT_DATABASE ‘FULL -~ there is no free entries in the LDT database 
- NO MEMORY - the function was unable to allocate the memory for the new 


LDT image segment 


Processing 


// Local variables 
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Success_Code return_code; // success or error code | 
Segment Idt_segment; // the segment which contains the LDT 
Selector Idt_selector; // the selector for the LDT image in the GDT 


return_code = SUCCEEDED; 

// the default case is to return a null entry 

Idt_id = NULL; 

if (Free _LDT_List << LDT_DATABASE MIN ENTRY) { 
return_code = LDT DATABASE FULL); } 

// allocate memory for the LDT, is unsuccessful, return the memory manager 

// error code | 

else if (return_code = kst_allocate_memory(LDT_SEGMENT_ SIZE, 
Idt_access_class,ldt_segment) != SUCCEEDED) | 

// add the allocated segment to the gdt 

else if (return_code = gdt_add_to_gdt(Idt_segment,ldt_selector) != 
SUCCEEDED) { : | 
// if we fail, deallocate the memory we just allocated 

kst_deallocate_memory(ldt_segment); } 

else { | 
Idt_id = Free LDT_ Entry; 
Free LDT Entry = LDT Database[Free LDT Entry] .next: 
LDT_Database[Idt_id].selector = ldt_selector; 
LDT_Database[Idt_id].segment = ldt_segment; 
LDT_Database[idt_id].first_free = 0; 
LDT_Database[Idt_id].free = FALSE; 
return_code = Idt_init_ldt(Idt_id); 

; 


return return_code; 
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Effects: 
e Ifsuccessful, the KST will contain a new segment for the LDT image, the GDT 
will contain an entry for the LDT image segment and the LDT database will 


contain a new entry for the LDT image. 
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c. Idt destroy Idt 
Function: ldt_destroy_ldt(Idt_id: LDT_Database_Entry) : Success Code Type 


Purpose: This function destroys an LDT image. The entry in the LDT database is 
added to the free list and the memory used by the LDT image is deallocated. 


Inputs: | 
e idt_id: LDT_Database_ Entry — an index into the LDT database, this is the 
entry that is destroyed. 


Outputs: 
e Success_Code — indicates the status of the operation. Possible values include: 
e SUCCEEDED -— The operation completed successfully 
- INVALID LDT DATABASE ENTRY ~ The ldt id provided did not 
point to a valid database entry 
- DEALLOCATION ERROR — an error occurred trying to deallocate the 
memory used by the LDT image | | 


Processing: 
// Local variables 
_ Success_Code_Type return_code; // success or error code 
return_code = SUCCEEDED; 


// check for a valid database entry 
if (idt_id < LDT_DATABASE MIN_ENTRY OR 
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Idt_id >= LDT_ DATABASE SIZE) { 
return_code = INVALID _LDT_DATABASE ENTRY; } 
// check that the entry being used is not free 
else if (LDT_Database[Idt_id].free == TRUE) { 
return_code = INVALID _LDT DATABASE ENTRY; } 
// deallocate memory and return error code is unsuccessful 
else if (kst_deallocate_ memory(LDT_Database[ldt_id].segment) != 
SUCCEEDED) { | 
retum_code = DEALLOCATION_ERROR; } 
// remove from the GDT, return error code if unseccessful 
else if (gdt_remove_from_gdt(LDT_Database[ldt_id].selector) != 
SUCCEEDED) { | 
return_code = DEALLOCATION_ ERROR; } 
// otherwise, remove the entry 
else { | 
// add the current enitry to the free list 
LDT_Database[Idt_id].next = Free LDT_Entry; 
// mark as free 
LDT_Database[Idt_id].free = TRUE; 
// current entry becomes head of free list 
Free LDT_Entry = Idt_id; } 


return return_code; 


Effects: 
e Ifsuccessful, the entry in the KST for the LDT image segment will be 
deallocated, the memory used by the LDT image will be deallocated and the 
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LDT database entry occupied by the LDT image will be added to the free 
. LDT database entry list and marked as free. 
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Idt_switch_Idt 
Function: Idt_switch_ldt(idt_id: LDT_Database_ Entry) : Success Code 
Purpose: This function makes a specified LDT image the current LDT. 


Inputs: 
e ldt_id: LDT_Database_Entry — the LDT image to make the current LDT 


Outputs: 

e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED — The operation completed successfully 
- INVALID LDT DATABASE ENTRY - The ldt id provided does not 


point to a valid database entry» 


Processing: 


// Local variables 


Success Code return_code; // success or error code 


return_code = SUCCEEDED; 
// check for valid LDT id 
if (idt_id << LDT DATABASE MIN ENTRY OR 
ldt_id >= LDT_DATABASE SIZE) { 
return_code = INVALID LDT DATABASE ENTRY; } 
// make sure the entry we are acting on is not marked free 


else if (LDT_Database[ldt_id].free == TRUE) { 
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return_code = INVALID LDT DATABASE ENTRY; } 
// switch the LDT register 
else { 

LDTR = LDT_Database[ldt_id].selector; } 


return return_code; 


Effects: | | 
e Ifsuccessful, the LDTR will contain a selector for the LDT image specified. 
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e. Idt_add_to ldt 


Function: Idt_add_to_ldt(ldt_id:LDT_Database_Entry,segment:Segment, 


access:Access_Class,selector:Selector) : Success_Code 


Purpose: This function adds a segment descriptor to the LDT image specified. A 
selector (index into the LDT) is returned. 


Inputs: 

e dt id: LDT Database Entry — identifies which LDT image the segment should 
be added to. _ 

e segment: Segment — the segment ID which should be added to the LDT 


e access: Access Class — the access class of the task making the request 


Outputs: | | 
e selector: Selector — the selector (index into the LDT) of the segment just added 
e Success_Code — indicates the result of the operation. Possible values include. 
- SUCCEEDED - the operation completed successfully 
- SECURITY VIOLATION — added the specified segment to the specified 
LDT image would violate the security policy 
- UNKNOWN_SEGMENT -— the segment specified does not correspond to a 
valid segment 
- INVALID_LDT_ DATABASE ENTRY — the LDT id provided does not — 
index a valid database entry 
- LDT_FULL — the LDT is full, no additions are possible 


Processing: 
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// Local variables 


Success Code —___ return_code; // success or error code 
Access Check access_chk; // access class of the LDT 
Selector Idt_image_selector; // the selector for the LDT 


return_code = SUCCEEDED; 
/! check for a valid LDT identifier 
if (idt_id << LDT_ DATABASE MIN ENTRY OR 
Idt_id >= LDT_DATABASE SIZE) { 
return_code = INVALID_LDT_DATABASE ENTRY; } 
else if (LDT_Database[Idt_id].free == TRUE) { 
return_code = INVALID_LDT_DATABASE ENTRY; } 
access_chk = kst_access_check(segment, access); 
// check for a valid segment - 
if (access_chk == UNKNOWN_SEGMENT) { 
return_code = UNKNOWN_SEGMENT: } 
// check for a policy violation 
else if (access_chk == SECURITY_VIOLATION) { 
| return_code = SECURITY_VIOLATION; } 
// check for a full LDT 
else if (LDT_Database[Idt_id].first_free < 0) { 
| return_code = LDT_FULL,; } 
// otherwise, add the segment to the LDT 
else { 
selector = LDT_Database[Idt_id].first_free; 
Idt_image_selector = LDT_Database[Idt_id].selector; 
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Get first free entry in LDT and set to first_ free; 


Insert selector into LDT at location first_free; 


} 

return return_code; 
} 
Effects: 


e If successful, the LDT image specified will have a new entry (descriptor) 
corresponding to the segment specified. The LDT image free list is updated to 


indicate that the entry just allocated is no longer free. 
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f. Idt_remove from _ldt 


Function: Idt_remove_from_Idt(idt_id: LDT Database Entry,selector:Selector) : 


Success Code 


Purpose: This function removes a descriptor for a specified LDT image. This 
function does not deallocate the segment. The segment still exists and must be 
explicitly deallocated by the calling process with a call to 


mm. deallocate_ memory. 


Inputs: 
e Idt_id: LDT_Database_Entry — an index in the LDT database specifying - 
which LDT image the descriptor should be removed from. 


e selector: Selector — the selector specifying which LDT entry is to be removed. 


Outputs: a 
e Success_Code — Indicates the result of the operation. Possible values include: 
® SUCCEEDED — The operation completed successfully. 

- INVALID. LDT DATABASE_ENTRY ~ The LDT id provided does not 
point to a valid database entry. | 
- INVALID SELECTOR -— The selector provided was invalid 


Processing: 


// Local variables 


Success_Code return_code; // success or error code 
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Selector ldt_image_selector;// LDT selector 


return_code = SUCCEEDED; 
// check for a valid LDT identifier 
if (Idt_id< LDT_DATABASE MIN ENTRY OR 
Idt_id >= LDT_DATABASE SIZE) { 
return_code = INVALID LDT_ DATABASE ENTRY; } 
else if (LDT_Database[ldt_id].free == TRUE) { 
retum_code = INVALID LDT DATABASE ENTRY; } 
// check for a valid selector | 
else if (selector < MIN _LDT_ENTRY OR selector >= LDT_SIZE) { 
return_code = INVALID_SELECTOR; } 
// otherwise, remove the item from the LDT 
else { 
Idt_image_ selector = LDT_Database[ldt_id].selector; 
*(Idt_image_selector:selector) = LDT_Database[Idt_id]-first free; 
LDT_Database[ldt_id].first_free = selector; 
return_code = SUCCEEDED; } 


return return_code; 


Effects: 
e Ifsuccessful, the specified selector in the specified LDT image is added to the 
free entry list. 
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2. GDT Manager 


The GDT manager of the memory manager handles those functions that 


manipulate the GDT and GDT images. This component provides the following services: 


e Create anew GDT image 

© Switch between GDT images 

e Destroy a specified GDT image 

e Addasegment to the GDT 

e Removes a segment from the GDT 

e Allocate a block of memory ~ 

e Deallocate a block of memory 

e Returns the descriptor associated with a segment id 

The GDT is logically divided into two sections. One part of the GDT holds 
descriptors used by the kernel and MLS queues (this part remains static during process 
Switches) and the other part holds descriptors used by the processes (this part gets 
swapped on a process switch). | 
a) GDT Manager Constants 

a. GDT_IMAGE SIZE — Size of the process section of the GDT. 

b. GDT_DATABASE SIZE — The number of entries in the database that tracks 
process GDT images | | 
KERNEL _GDT_SIZE — Size of the kernel section of the GDT. 
PROCES _GDT_SIZE — Size of the process section of the GDT 
e. GDT_DATABASE MIN - The minimum value used to index the GDT database. 
END_OF_ LIST — Used to denote the end the list of free entries 
g. GDT_MIN — The minimum value used to index the GDT itself (on Pentium 


a 9 


a 


architectures this will usually be 0). 


h. KERNEL GDT — Indicates that kernel section of the GDT is being acted on. 
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i. PROCESS _GDT - Indicates that the process section of the GDT 1s being acted 
on. 
b) GDT Manager Databases 
a. Process GDT Database (GDT_DATABASE) 


This database stores information about the GDT image associated with each 
process. Unlike the LDT, where a switch only requires the changes of one 
eee value, a GDT switch requires the copying of the current values of the 
GDT into a GDT image and the copying of a new GDT image into the GDT. 


Each GDT_DATABASE entry stores information about one process GDT image 


struct GDT_Database_Entry { 


selector: Selector; // the GDT selector for the GDT image 
segment: Segment; // segment id for the GDT image 

free list[GDT_IMAGE_ SIZE]: Integer; // free entry map | 
first_free: Integer; // index to first free entry 


next: GDT_Database_Entry; // link to next entry in free list 


The process GDT database stores information about each process GDT image. 
The GDT image id corresponds to an index into the array. 


struct GDT_Database_Entry GDT_DATABASE[GDT_DATABASE SIZE]; 


b. Kernel GDT Free Table 
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This database keeps a map of the free and available entries in the kernel section of 


the GDT. Is simply a linked list stored as an array. 
This database maps the free slots in the — section of the GDT 
KERNEL _GDT_FREE[KERNEL GDT_SIZE] Integer; 

c) GDT Manager Global Variables 
GDT DATABASE FIRST FREE — Points to the first GDT database entry that is | 
available. This entry then points to the next free entry and so forth. An entry of 


NIL indicates that there are no free entries. 


. KERNEL GDT_FIRST_FREE — Points to the first free GDT slot in the kernel 
section of the GDT. This is an index into the KERNEL_GDT_FREE table. 
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ad) GODT Manager System Calls 
a. gdt create gdt 
Function: gdt_create_gdt(gdt_id:GDT_Database_ Entry): Success Code 


Purpose: This function creates a new process GDT image storage area and passes 


back the if associated with the GDT image. 
Inputs: None 


Outputs: 

e gdt id: GDT_Database_Entry — the index into the GDT database associated 
with the process GDT image just created. 

e Success_Code — indicates the results of the operation. Possible values 
include: | | 
- SUCCEEDED - the operation competed successfully 
- GDT DATABASE FULL — there are no free slots in the GDT database 
- NO MEMORY — the function was unable to allocate memory for the new 

GDT image 


Processing: 


{ 
// Local variables 
Sucdess_ Code return_code; // stores return code 
Segment gdt_segment; // stores GDT image segment id 
Selector gdt_selector; // stores GDT image GDT selector 
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return_code = SUCCEEDED; 

gdt_id = NULL,;// initialize return parameter to NULL 

// check for free entry in the GDT database 

if (GDT_DATABASE FIRST FREE < GDT_DATABASE MIN) { 
// if none, set return code | 
return_code = GDT DATABASE FULL; } 

// else, try to allocate memory for the GDT segment 

else if { {kst_allocate_ memory(GDT_ IMAGE SIZE,SYSTEM _ CLASS, 

gdt_segment) != SUCCEEDED) 
// if the memory allocation fails, set return code 
return_code = NO MEMORY; } . 

// else, try to add the just allocated segment to the kernel GDT 

else if { (gdt_add_to_gdt(Idt_segment, KERNEL GDT, 
gdt_selector) != SUCCEEDED) 
// if the attempt to add to the kernel’s GDT fails, set return code 
return_code = NO MEMORY; } 

// otherwise, initialize the GDT image and return 

else { 
//-the current free GDT entry is the one we use, and we set the free 
// entry to the next in the list 
gdt_id = GDT_DATABASE FIRST_FREE; 
GDT_DATABASE FIRST FREE = | 

GDT_Database[GDT_DATABASE FIRST _FREE].next; 

// initialize the current GDT entry 
GDT_Database[gdt_id].selector = gdt_selector; 
GDT_Database[gdt_id].segment = gdt_segment; 
// initialize the free list for the new GDT image 


03 





for (index = 1 to GDT_SIZE) { 
GDT_Database[gdt_id].free_list[index] = index+1]; } 
GDT_Database[gdt_id].free_list[index] = END OF LIST; 
GDT_Database[gdt_id].first_ free = GDT_MIN; 
// This is an active entry, so the next points to nothing 
GDT_Database[gdt_id].next = END OF LIST; 

} 


return return_code; 


_ Effects: 

e Ifsuccessful, the GDT database will contain a new entry corresponding to a 
new process GDT image. All entries in the new GDT will be marked as free 
and the index associated with the new GDT image will be returned to the 


caller. | 
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b. gdt_destroy_gdt 
Function: gdt_destroy_gdt(gdt_id:GDT_Database_Entry): Success Code 


Purpose: This function destroys a GDT image. The entry in the GDT database is 
added to the free list and the memory used by the GDT image is deallocated. 


Inputs: | 
¢ gdt_id: GDT_Database_Entry — an index into the GDT database indicating 
which GDT image should be deallocated. 


Outputs: 
e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully 
- INVALID _GDT_ENTRY —The git it provided is not valid 
- DEALLOCATION ERROR — An error occurred trying to deallocate the 
memory used by the GDT image 


Processing: 


// Local variables 


Success Code return_code; // stores the return code 


return_code = SUCCEEDED; 

// Check for a gdt_id within the proper range 

if (gdt_id <GDT_DATABASE MIN) OR 
(gdt_id >= GDT DATABASE SIZE) { 
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.// if invalid, set the return code 
return_code = INVALID _GDT_ENTRY; } 
// otherwise, try to deallocate the memory used by the GDT image 
else if (kst_deallocate_memory(GDT_Database[gdt_id].segment) != 
SUCCEEDED) { 
// 1f unsucceessful, set the return code 
return_code = DEALLOCATION_ERROR; } 
// attempt to remove the descriptor from the GDT 
else if (kst_remove_from_gdt(KERNEL_ GET, 
GDT_Database[gdt_id].selector) != SUCCEEDED) { 
// if unsuccessful, set the return code | 
return_code = DEALLOCATION_ERROR; } 
// finally, if we get this far, update the GDT database to remove the entry 
else { 
// add the GDT entry to the beginning of the free list 
GDT_Database[gdt_id].next = GDT_ DATABASE FIRST FREE; 
GDT_DATABASE FIRST FREE = gdt_ id; | | 
return_code = SUCCEEDED; 
} 


return return_code; 


Effects: 
If successful, the memory used by the GDT image is deallocated, the segment 


is removed from the Known Segment Table, the selector for the GDT image is 


removed from the GDT and the entry in the GDT database is added to the list 


of available entries. 
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gdt_ switch edt 


Function: gdt_switch gdt(old_gdt id:GDT Database Entry, 
new_gdt_id:GDT_Database_Entry): Success_Code 


Purpose: This function swaps out the current process GDT image to the specified 
GDT image storage area and swaps in the process GDT image from the specified | 


GDT image storage area. 


Inputs: | 

e old _gdt id: GDT Database Entry — the GDT image witch should be swapped 
out. Note, the memory manager has no way of knowing which process is 
currently running, thus the caller of this routine must specify the currently running 
process GDT image area. | 


e new_gdt_id: GDT_Database_ Entry —- the GDT image to swap in. 


Outputs: | 
e Success Cod — indicates the result of the operation. Possible values include: 
- SUCCEEDED -— The operation completed successfully 
-  INVALID_GDT_DATABASE ENTRY — One of the GDT database entries 
provided does not point to a valid entry in the GDT database. 


Processing: 


// Local variables 


Success _Code return_code; // stores the return code 
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return_code = SUCCEEDED; 
// Check for an GDT database index input out of range 
if (old_gdt_id <GDT_ DATABASE MIN) OR 
| (old_gdt_id>GDT DATABASE. SIZE) OR 
(new_gdt_ id << GDT_DATABASE MIN) OR 
(new_gdt_ id > GDT_DATABASE SIZE) 
// Set return code to indicate invalid entry 
return_code = INVALID GDT_ DATABASE ENTRY; } 
// Otherwise, perform the swap 
else { 
// Copy the contents of the GDT process image to the old process area 
memcopy(GDT: IMAGE SELECTOR:0, 
GDT_DATABASE/fold_gdt_id].selector:0, GDT_IMAGE_SIZE),; 
// Copy the contents of the new GDT process image into the GDT 
memcopy(GDT_DATAB ASE[new_gdt_id].selector:0, 
GDT IMAGE _SELECTOR:0, GDT_IMAGE SIZE); 
} 
// return success code 


return return_code; 


Effects: 
e If successful, the current contents of the GDT process area will be copied to the 
| specified GDT process image storage area and the contents of the new GDT 


process image storage area will be copied into the GDT process area. 
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d. gdt_add_to_gdt 


Function: gdt_add_to_gdt(segment:Segment, gdt_id:GDT_Database_ Entry, 


gdt_selector: Selector) : Success Code 


Purpose: This function adds a specified segment to either the process GDT or the 
kernel GDT (the two parts of the physical GDT). A segment can only be added to the 
current process GDT image since this function acts on the GDT and not any of the 
images stored elsewhere. The kernel area of the GDT requires not special handling 


since it remains static during process switches. 


aac 

e segment: Segment — the segment id (index into the KST) for the segment that 
should be added the GDT 

e gdt_id: Segment — the identifier for the GDT image to add the segment to. If this 
value is set to KERNEL GDT, that indicates that the segment should be added to 
the kernel section of the GDT otherwise the segment is added to the process 
section of the GDT. | 


Outputs: 
e selector: Selector — a selector into the GDT for the segment just added 
e Success Code — Indicates the results of the operation. Possible values include: 
-- SUCCEEDED - The operation completed successfully. 
- NO MEMORY - The specified GDT is full 
- INVALID _GDT DATABASE ENTRY — The GDT id is invalid 
- INVALID_SEGMENT — The segment provided does not correspond to a 


real segment 
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Processing: 


f 
// Local variables 
Success Code — retum_ code; // stores the return code 
Descriptor seg desc; // the descriptor to add 


/} Check for gdt_id within range 
if (((gdt_id <GDT_ DATABASE MIN) OR 
(gdt_id >= GDT DATABASE SIZE)) 
AND (gdt_id!=KERNEL GDT)) { 
// if invalid, set the return code 
return_code = INVALID GDT_DATABASE ENTRY; } 
// otherwise, check for an available entry if kernel GDT 
else if ((gdt_id == KERNEL _GDT) AND 
(KERNEL _GDT_FIRST FREE <GDT_ DATABASE MIN)) { 
// if no free entries in kernel GDT 
return_code == NO MEMORY; } 
// otherwise, check for an available entry if we are adding to the 
// process GDT 
else if ((gdt_id != KERNEL _GDT) AND 
(GDT_Database[gdt_id].first_free< GDT_ DATABASE MIN)) { 
// if no free entries in process GDT 
return_code == NO MEMORY; } 
// check for a valid segment by trying to get its associated descriptor 
else if ((seg desc =mm_get_descriptor(segment)) != 


SUCCEEDED)) { 
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// if we can’t get the descriptor, then the seg id is invalid 
return_code = INVALID SEGMENT; } 
// finally, is we can actually update the GDT 
else { | 
// if we are adding to the kernel section of the GDT 
if (gdt_id == KERNEL GDT) { 
Assign the first free slot in the kernel GDT to selector; 
Update the kernel GDT free list; 
Add the descriptor to GDT at selector; 


// otherwise, we are adding to the process GDT 


else { | | 
Assign the first free slot in the kernel GDT to selector; 
Update the kernel GDT free list; 
| Add the descriptor to GDT at selector; 
} 
return return_code; 
} 
Effects: | 


e Ifsuccessful, the descriptor for the segment passed in is added to either the 
kernel or process section of the GDT and the appropriate free list is updated. 


A selector for the GDT entry added is passed back to the caller. 
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e. gdt remove from _gdt 


Function: gdt_remove_from_gdt(get_id: GDT_Database_Entry,selector:Selector): 


Success Code 


Purpose: This function removes an entry from the GDT, either the kernel or process 
section. The slot occupied by the removed selector is added to the appropriate free 
list. This function only removes the selector, the segment and the memory it occupies 


must be explicitly deallocated by the caller. 


Inputs: 
e get_id: GDT_Database_Entry — The id of the GDT image to delete the selector 
from, or the kernel GDT 


e selector: Selector — the selector to remove from the GDT 
Outputs: 
e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - the operation completed successfully. 
- INVALID _GDT_DATABASE ENTRY -— the GDT image specified is invalid 
- INVALID SELECTOR - the selector specified is invalid 
Processing: 
// Local variables 


Success Code return_code; // stores the return code 


return_code = SUCCEEDED; 
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// First, check for a valid gdt_id 
return_code = SUCCEEDED; 
if ((gdt_id != KERNEL _GDT) AND ((gdt_id) < GDT_DATABASE MIN) 
OR (gdt_id >= GDT_DATABASE SIZE)) { | 
// if invalid entry, set return code 
return_code = INVALID_GDT DATABASE ENTRY; } 
// otherwise, if we are operating on the kernel GDT, check for 
// valid selector range 
if ((gdt_id == KERNEL_GDT) AND 
(selector <GDT_MIN) OR .- 
selector >= KERNEL _GDT _SIZE)) { 
// if selector out of range for kernel table, set return code 
return_code = INAVLID_SELECTOR; } 
// otherwise, 1f we are operating on the process GDT, check for 
// valid selector range 
if ((gdt id |= KERNEL GDT) AND 
| (selector <GDT_MIN OR 
selector >= PROCESS _GDT SIZE)) { 
// if selector is out of range, set return code 
return_code = INVALID SELECTOR; } 
// otherwise, actually remove the selector 
else f | 
// if we are operating on the kernel GDT 
if (gdt_id == KERNEL GDT) { 
Add the selected GDT entry to the kernel GDT free list; 
Initialize the descriptor so it is no longer valid; 
// otherwise, remove from process GDT 


Add the selected GDT entry to the process GDT free list; 
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Initialize the descriptor so it is no longer valid; 


} 
} 
return return_code; 
} 
Effects: 


e If successful, this process will blank a selector from the GDT (either kernel or 
process sections) and add the blanked slot to the list of available GDT slots. 
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3. KST Manager 


The KST manager of the memory manager handles those functions that manipulate the 


KST. This component provides the following services: 


e Allocate a block of memory 
° Deallecate a block of memory 
e Returns the descriptor associated with a segment id 
a) KST Manager Constants | 
a. KST_MIN— Minimum value used to index the KST. 
b. KST_ MAX — Maximum value used to index the KST 
c. KST_ SIZE — The size of the KST. | 
b) KST Manager Databases 
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Known Segment Table (KST) 
This table maps segment id’s to their associated descriptors and security attributes. 


// The KST is an array of KST entry records. The index into the KST serves 


// as the segment identified. 

struct KST_Entry KST[KST_SIZE]; 

// Each KST entry stores information about one segment 
struct KST Entry { 


descriptor: Descriptor; // descriptor associated with this segment 


access: Access_Class;// access class associated with segment 
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next: KST_ Entry; // next KST entry in free list 
c) KST Manager Global Variables — 


a. KST_FIRST_FREE — Points to the first free KST slot. If this index is less than 0, we 


can no longer add segment to the system. 
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d) KST Manager System Calls 


a. kst_allocate_ memory 


Function: kst_allocate_memory(size:Integer, access_class:Access_ Class, 


segment:Segment) : Success Code 


Purpose: This functions allocates a block of memory of the appropriate size and 
creates a descriptor that is added to the known segment table. The index into the 


know segment table that corresponds to the added segment is returned to the caller. 


Inputs: . 
e size: Integer — the size of the memory block to allocated (in bytes). 
e access class: Access Class — the label to associated with the newly created 


segment 


Outputs: 
e semgnet: Segment — the segment id iesoeiated with the newly created segment 
e Success_Code — indicates the result of the operation. Possible values include: | 
- SUCCEEDED -— the operation completed successfully | 
- NO MEMORY - there is no memory to allocate 
- KST FULL — there are no more available entries in the KST 


Processing: 


// Local variables 


Success_Code return_code=NULL; // stores return code 
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Descriptor seg desc; // descriptor for the new segment 


return_code = SUCCEEDED; 
// make sure we have an available slot in the KST 
if KST_ FIRST FREE <KST_MIN) { 
// if not, set return code 
return_code = KST_ FULL; } 
// otherwise, create and assign the descirptor 


else { 


// ***** allocate physical memory at this point, create 
// ***** descriptor and assign to seg desc. If there 
// ***** isn’t enough physical memory, set return to 


|| ***** NO. MEMORY 


//if memory was successfully allocated 
if (return_code != NO_MEMORY) { 
// assign the segment number 
segment = KST_FIRST_FREE; 
KST_FIRST FREE = KST[KST_FIRST_FREE].next; 
// assign descriptor and access class to new segment 
KST[segment].descriptor = seg_desc; 


KST[segment].access = access_class; 


} 


return return_code; 
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Effects: 

e Ifsuccessful, physical memory is allocated and a descriptor is created, this 
descriptor is added to the know segment table with the supplied access class. 
The index into the KST which identifies the new segment is passed back to 


the caller. 
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b. kst_deallocate_memory 
Function: kst_deallocate_memory(segment:Segment) : Success_Code 


Purpose: This function deallocates memory associated with a segment id and adds the 


KST slot to the list of free slots 


Inputs: 
e segment: Segment — the index into the KST which identifies the segment to be 


deallocated 


Outputs: 

e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - the operation completed successfully 
- INVALID SEGMENT ~— the segment provided is invalid 
- DEALLOCATION_ERROR - an error occurred during deallocation of 


memory 
Processing: 
// Local variables 
Success_Code return_code = NULL; // save return code 
// check for valid segment 
if (segment < KST_MIN) OR (segment > KST_MAX) { 


// if invalid, set return code 


return_code = INVALID_SEGMENT; } 
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// otherwise, perform the deallocation 
else 
// ***** T)eallocate the physical memory associated with 
// ***** the descriptor KST[segment].descriptor. If there 
// ***** is an error performing the deallocation, set 
// ***** return code to DEALLOCATION_ERROR. Also, 
/] ***** deallocated memory should be wiped to prevent 


}]/ *¥*** reyse 


// if memory was successfully deallocated 
if (return_code != DEALLOCATION_ERROR) { | 
// add segment to free list | 
KST[segment].next = KST_FIRST_FREE; 
KST_FIRST FREE = segment: 
// blank descriptor and access to prevent reuse 
KST[segment].descriptor = BLANK DESCRIPTOR; 
KST{segment].access = NO_ ACCESS; 


} 


return return_code; 


Effects: . 
e If successful, the KST entry for the specified segment should be blanked and that 
entry added to the list of available entries. Also, the memory associated with the 


segment should be deallocated. 
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c. kst_get descriptor 
Function: kst_get_descriptor(segment:Segment, seg_desc:Descriptor) : Success_Code 
Purpose: This functions returns the descriptor associated with a segment in the KST. 


Inputs: 


¢ segment: Segment — the segment id for which the descriptor is sough 


Outputs: 

e seg desc: Descriptor — the descriptor associated wilh the requested segment 

e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED ~ the operation completed successfully 
- INVALID SEGMENT - the request segment is invalid 


Processing: 


// Local variables 


Success Code return_code; // stores the return code 


// check for a valid segment id _ 

if (segment < 0) OR (segment >= MAX _KST_SIZE) { 
// if invalid, set return code 
return_code = INVALID_SEGMENT; } 

// otherwise, return the descriptor 

else { 


seg desc = KST[segment].descriptor; 
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// set return code 


return_code = SUCCEEDED; 


} 

return return_code; 
} 
Effects: 


e This system call does not alter the state of the system if successful. 
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B. PROCESS MANAGER (PM) 
The process manager is responsible for managing the multiple processes in the system. 


Some of its functions include: 


e Create new processes 
e Destroys processes 

e Switches processes 

e Changes process status 


e Return the current process 


1. Process Manager Constants 


MAX PROCES SES — The maximum number of processes the system can manage. 
b. MIN PROCESS - The least value that can be used to index the process table. 
c. MAX PROCESS — The maximum value that can be used to index the process table. 


2. Process Manager Databases 


a. Process Database 
The process database keeps information about the process currently in the system. 
This includes context, current status, and GDT image. The process id is the index 


into this table. 


The process database is an array of process entries. It is set to the maximum number 


of processes the system can handle 
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struct Process_Entry Process_Database[MAX_ PROCESSES]; 
Process entries store information about each process 


struct Process Entry { 
gdt_id: GDT_Database Entry; // the GDT image for this process 


status: Process_Status; // the current process status 
context: Process_Context; _ // the saved process context 
previous: Process_Entry; // previous process entry in list 
next: Process Entry; - // next process entry in list 


3. Process Manager Global Variables 


. FREE PROCESS HEAD & FREE PROCESS TAIL — ~ point to the head and tail of 


the list of free process entries 


. READY_PROCESS_HEAD & READY PROCESS TAIL - point to the head and 


tail of the list of ready processes 


. BLOCKED_PROCESS_ HEAD & BLOCED PROCESS TAIL — points to the head 
_ and tail of the list of blocked processes 


. CURRENT_PROCESS - the index of the entry for the running process 
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4. Process Manager System Calls 


a. pm_switch_process 


Function: pm_switch_process() 


Purpose: This function runs the next ready process and suspends the current process. 


Inputs: None. 


Outputs: None. 


Processing: 

{ 
// Local variables 
Process Entry current_process; // the currently running process 
Process Entry next_process; // the next process to be run 


return_code = SUCCEEDED; 

// Save the current processes context — the caller should handle putting 

// the current process on the appropriate blocked queue 
save_context(Process Database[ CURRENT PROCESS].context); 

// Wait until there is a ready process available 

while((next_process = READY PROCESS HEAD) > MIN PROCESS); 
// Switch the process GDT images 

mm_ switch gdt(Process Database[ CURRENT PROCESS].gdt_id, 
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Process Database[next_process].gdt_id; 
/! Move new process from READY to RUNNING 
pm_change_process_status(next_process,RUNNING); 
// Restore the new process context 
restore_context(Process_Database[next_process].context); 
// **** magic point — at this point we are in the new process; 


return; 


Effects: | 
e When this process returns, the system will be running the next available ready 


process. 
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b. pm_create process 


Function: pm_create_process(process 


parameters[TBD],new_process:Process_ Entry): SuccessCode 


Inputs: TBD. 


Outputs: 


new_ process: Process Entry — the entry in the process database corresponding to 

the new process added 

SuccessCode — Indicates the result of the operation. Possible values include: 

- SUCCEEDED - the operation completed successfully _ 

- PROCES S TABLE FULL — there are no more available entries in the 
process table 

- GENERAL ERROR - the process could not be created due to some other 


condition 


Processing: 


- // Local variables 


Process_Entry new process; // the id of the new process 
Success _Code - return_code; // holds the return code 
GDT_Database_Entrygdt_id; // holds GDT image for new process 


return_code = SUCCEEDED; 
// Check for available slots in the process database 


if (FREE PROCESS HEAD <0) { 
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// set return code to indicate no free slots 
return_code = PROCESS TABLE FULL } 

// Otherwise, Initialize a new GDT image for this process 

else if (gdt_id = mm_create_gdt(gdt_id) != SUCCEEDED) { 
// if we can’t create a gdt image, set error code | 
return_code = GENERAL ERROR; } 

// **** Perform other checks as needed 

else if (...) { } 

// otherwise, initialize the entry 

else 4 

| // assign the process id 

new_process = FREE PROCESS HEAD; 

// assign the process GDT image 

Process_Database[new_process] = gdt_id; 

// **** Jnitialize memory as needed 

// Add the new process to the ready list 

if (pm_change_process_status(new _process,READY) [= 
SUCCEEDED) { | 
// if we couldn’t make the process ready, error 
return_code = GENERAL ERROR } 


} 

return return_code; 
. 
Effects: 


e Ifsuccessful, the function will remove an process entry from the free list, 
initialize a GDT image and other memory, and add the new process to the ready 


list. 
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c. pm_destroy_process 
Function: pm_destroy_process(process_id:Process_Entry): SuccessCode 


Inputs: 


e process id: Process Entry — the process to destroy 


Outputs: 
° Success _Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - the operation succeeded 
- INVALID PROCESS - the process id provided was not valid 
- DEALLOCATION_ ERROR — an error occurred deallocating memory 
- FAJLED — the operation failed 


Processing: 


// Local variables . 


Success Code return_code; // holds the return code 


return_code = SUCCEEDED; 

// Make sure the process id is valid 

if ((process id <MIN_ PROCESS) OR (process_id > MAX PROCESS) 
OR (Process _Database[process_id] = FREE)) { 
// the operation fails if the id is invalid 
return_code = INVALID_PROCESS; } | 

// Try to deallocate the memory used by the GDT image 
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else if (mm_destory_gdt(Process_Database[process_id].gdt_id != 
| SUCCEEDED) { 
// if we can’t, we have an error 
return_code = DEALLOCATION_ERROR; } 
// otherwise, remove the process 
else { 
// move the entry to the free list 
if (pm_change_process_status(process_id,FREE) != 
SUCCEEDED) { . 
// if we can’t, we have an error 
return_code = FAILED; } 
} 


return return_code; 


Effects: 


e Ifsuccessful, this function will remove the specified process from whichever list 


it is currently on, deallocate its GDT image and will move the process entry to the * 
free list. | 
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d. pm_change process status 


Function: pm_change_process_status(process_id: Process Entry, 


new_status:Process_ Status): Success_Code 
Purpose: This function changes the status of a specified process. 


Inputs: 
e process_id: Process Entry — the process we want to change the status of. 


e new status: Process Status — the new status for the process 


Outpust: 
_@ Success_Code ~ indicated the result of the operation. Possible values include: 
e SUCCEEDED —~ the operation succeeded 
- INVALID STATUS - the new status is not valid 
- INVALID PROCESS - the process in not valid 


- FAILED — the operation failed for some other reason 


Processing: 

{ 
// Local variables 
Success Code return_code; // holds the return code 
Process_ Entry prev; // temp used for list manipulation 
Process_Entry next; // temp used for list manipulation 


return_code = SUCCEEDED; 


82 





// Checks for a process id within bounds 
if.((process_id < MIN PROCESS) OR (process_id > MAX _PROCESS)) { 
// if out-of-bound, set error code 
return_code = INVALID PROCESS; } 
// check for a valid status 
else if (new_process NOT IN {RUNNING,FREE,BLOCKED,READY}) { 
// if not a valid status, set error code 
return_code = INVALID STATUS; } 
// otherwise, make the change | 
else { 
// first, if the new status is the same as the old status we are done 
if (NOT(Process_Database[process_id].status = new_status)) { 
// otherwise, remove the process from the old list 
switch Process Database[process id].status { 
// if current process is running, it doesn’t have to 
// be removed from any list 
case RUNNING: 
break; 
// item is on the blocked list 
case BLOCKED: 
// if the previous item in the list is empty, 
// we are at the head 
if (Process Database[process_id].previous 
<MIN_ PROCESS) { 
BLOCKED PROCESS HEAD = 
Process Database[process_id].next; } 
// if the next item in the list is empty, we are at the 
// tail 
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if (Process _Database[process_id].next < 
MIN_PROCESS) { 
BLOCKED PROCESS _ TAIL = 
Process _Database[process_id].previous; } 
// if not at the head or the tail, remove item from list 
if (NOT(Process_Database[pcoress_id].next 
< MIN PROCESS) AND 
NOT(Process_Database[process_id].previous < 
MIN _PROCESS)) { 
next = Process _Database[process_id].next; 
prev = 
Process Database[process_id].previous; 
Process Database[prev].next = next; 
Process _Database[next].previous = prev; } 
break; 
// process is on the ready list 
case READY: 
// if previous item in the list is empty, we are at the 
// head 
if (Process _Database[process_id].previous < 
MIN_PROCESS) { 
READY PROCESS HEAD = 
Process _Database[process_id].next; } 
// if the next item in the list is empty, we are at the 
// tail 
if (Process Database[process_id].next < 
MIN _ PROCESS) { 
READY PROCESS TAIL = 
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Pprocess_Database[process_id].previous; } 
// if at the head or the tail, remove item from list 
if (N OT(Process Database[pcoress id].next <- 
MIN_PROCESS) 
AND | 
NOT(Process_Database[process_id].previou 
s <MIN_PROCESS)) { 
next = Process Database [process _id].next; 
prev = | 
Process Database[process_id].previous; 
Process Database [prev] next = next; 
Process_Database[next].previous = prev; } 
break; 
// process is on the free list 
case FREE: | 
// if previous item in the list is empty, we are at the 
/I head | a 
if (Process_Database[process_id].previous < | 
MIN_ PROCESS) { 
FREE PROCESS HEAD = 
Process_Database[process_id].next; } 
// if the next item in the list is empty, we are at the 
[tail 
if (Process Database[process_id].next < 
_ MIN_PROCESS) { 
FREE PROCESS TAIL = | 
Pprocess_Database[process_id].previous; } 


// if at the head or the tail, remove item from list 
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if (NOT(Process_ Database[pcoress_id].next < 
MIN_PROCESS) AND © 
NOT(Process_Database[process_id].previous < 
MIN_PROCESS)) 
next = Process Database[process_id].next; 
prev = 
Process Database[process_1d].previous; 
Process_Database[prev].next = next; 
Process _Database{next].previous = prev; } 
break; 
// otherwise, we have an error 
case default: 
| return_code = FAILED; 
} 
// now we add the process to the new list 
switch new_status { 
// if we are making the process running, don’t do anything 
case RUNNING: 
break: 
// working on the blocked list 
case BLOCKED: 
// if new list is empty, set head to new process 
if (BLOCKED PROCESS HEAD = 
BLOCKED PROCESS TAIL = -1) { 
BLOCKED PROCESS HEAD = process _id; 
BLOCKED PROCESS TAIL = process id; } 
// otherwise, just add to the end of the list 


else { 
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Process_Database[ BLOCKED PROCESS _TAIL].next 
| = process_id; 
Process_Database[process_id].next = 
END_OF LIST; 
Process Database[process_id].previous = 
BLOCKED PROCESS TAIL; 
BLOCKED PROCESS TAIL = process. id: 
} 
break; 
// working on the ready list 
case READY: 
[if new list is empty, set head to new process 
if (READY PROCESS HEAD = 
READY PROCESS TAIL = END_OF_LIST) { 
READY PROCESS HEAD = process id; 
READY_PROCESS_TAIL = process_id; } 
// otherwise, just add to the end of the list 


else { 


Process_Database[READY PROCESS TAIL].next = 
process_id; 
Process Database[process_id].next = 
END_OF LIST; 
Process_Database[process_id].previous = 
READY PROCESS TAIL; 
READY PROCESS TAIL = process_id; 
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break; 
// working on the FREE list 
case FREE: 
// if new list is empty, set head to new process 
if (FREE PROCESS HEAD = 
FREE PROCESS. TAIL = -1) { 
FREE PROCESS HEAD = process_1id; 
FREE PROCESS TAIL = process_1id; } 
// otherwise, just add to the end of the list 


else { 


Brocess: Datebasere REE PROCESS TAJL}.next = 
| process_id; 
Process _Database[process_id].next = 
_ END_OF LIST; 
Process Database[process_ id].previous = 
FREE PROCESS TAIL; 
_ FREE PROCESS TAIL = process id; 
} | 
break; 
case default: 
return_code = FAILED; 
} 
// change the process status field 


Process Database[process_id].status = new_ status; 


} 


return return_code; 
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Effects: 


e If successful, this function will move a given process from one process status list to 


another and rest the process status field 
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C. KERNEL EVENT MANAGER (KEM) 


The process event manager controls the kernel eventcounts. These eventcounts are used 
for synchronization and scheduling (through the queue managers.) The functions 


provided include: 


e Create a new eventcount 
e Delete an eventcount 

e Advance an eventcount 
e Wait on an eventcount 

e Create a new sequencer 
e Delete a sequencer 


e Geta ticket from a sequencer 


1. Kernel Event Manager Constants 
a. MAX EVCT = The number of kernel eventcounts the aiid will pan 
b. MIN_EVCT — The smallest eventcount identifier 
c. MAX SEQ - The number of kernel sequencers the system will support. 
d. MIN SEQ - The smallest sequencer identifier 


e. END OF LIST — The end of the free list. 
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f. INIT_VALUE - The value used to initialize eventcounts and sequencers 


2. Kernel Event Manager Databases 


a. Kernel Event Database 
The kernel event database keeps track of the kernel eventcounts and their values. 
// Kernel event entries store information about each eventcount 
struct Kernel Event Entry { 
Integer: count; // the value of the eventcount 
// a list of processes which are blocked on this eventcount 
List of <process_id, wait_value> pairs: blocked; | 
Evct_Status : statue; // The eventcount statue 
Integer: next; // chains the free list 
// The kernel eventcounts 
Array of Kernel_Event_Entry : KED[MIN, EVCT..MAX EVCT}; | 
b. Kernel Sequencer Database 


The kernel sequencer database keeps track of the sequencers and their values 


Kernel sequencer entries store information about each sequencer 
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struct Kernel Seq Entry { 
Integer: value; // the value of the sequencer (unsi ened) 
Evct_Status: status; // the status of the eventcount 
Integer: next; // chains the free list together 


The sequencer database stores the sequencers 


Array of Kernel_Seq_Entry : KSD[MIN_SEQ..MAX_ SEQ); 


3. Kernel Event Manager Variables 


a. KED Free Head — The first free slot in the KED 


b. KSD_Free_Head ~ The first free slot in the KSD 
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4. Kernel Event Manager Functions 


a. ked_ create evct 
Function: ked_create_evct(Integer: evct): Success_Code 
Purpose: Allocates a new evenctcount, initializes it and returns it to the caller. 
Inputs: None. 


Outputs: 

e Integer: evct — An index into the KED which is the identifier for the new 
eventcount - 

e Success_Code — Indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully _ | 
- NONE AVAILABLE — No empty eventcounts are available 
- FAILED — The operation was unable to complete successfully 


Processing: 
// Local variables | 
Success Code return_code; - // success or error code 
return_code = SUCCEEDED; 


if (KED_ Free Head == END _OF LIST) { 


// set error code 
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. return_code = NONE_AVAILABILITY; } 
// otherwise, allocate the eventcount 
else { 
evct = KED Free Head; 
KED[evct}.value = 0; 
| KED Free Head = KED[evct] next; 
| 


return return_code; 


Effects: | 
e If successful, a new eventcount is allocated, initialized and returned to the 


caller. 
. ked_destroy_evet 
Function: ked_destroy_evct(Integer: evct): Success Code 


Purpose: This function destroys a specified eventcount by returning it to the free 
list. 


Inputs: 


e Integer : evct — The identifier for the evenctounc we would like to delete 


Outputs: 

e Success_Code — Indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully 
- INVALID_EVCT —- The specified eventcount is not valid 
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- FAILED — The operation did not complete successfully 


Processing: 


// Local variables 


Success Code return_code; // success or error code 


return_code = SUCCEEDED; 

// check for valid eventcount identifier 

if (evet < MIN_EVCT OR evct > MAX EVCT) { 
return_code = INVALID _EVCT; } 

else if (KED[evct].status  IN_USE) { 
return_code = FAILED; } 

// otherwise, deallocate the eventcount 

else { | 
KED[evct] next = KED Free Head: 
KED Free Head = evct; 
return_code = SUCCEEDED; 

} 


return return_code; 


Effects: 
e Ifsuccessful, the specified eventcount is added to the free list and is no longer 


available. 
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c. ked advance _evct 
Function: ked_advance_evct(Integer: evct): Success Code 


Purpose: This function advances the specified eventcount and will unblock any 


processes which are waiting on the new eventcount value 


Inputs: 


e Integer: evct — The eventcount to advance. 


Outputs: 

e Success Code — Indicated the result of the operation. Possible values include: 
- SUCCEEDED — The operation completed successfully | 
- INVALID EVCT - The specified eventcount was not valid 
- FAILED — The operation did not complete successfully. 


Processing: 


// Local variables 


Success Code return_code; // success or error code 


return_code = SUCCEEDED; 

// check for valid eventcount identifier 

if (evct < MIN EVCT OR evct > MAX EVCT) { 
return_code = INVALID _EVCT; } 

else if (KED[evct].status # IN USE) { 
retum_ code = INVALID _EVCT; } 
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else { 
// advance the eventcount 
KED|evct].value = KED[evct].value + 1; 
for each <process id, wait_value> pair in KED[evct].blocked { 
// if a process is waiting on the new value, unblock it 
if (wait_value <= KED[evct].value) { 
pm_change process _status(process id, READY); 
remove <process id, wait_value> from 
KED[evct].blocked; 


} 


return return_code; 


Effects: 
e Ifsuccessful, the specified eventcount is advanced and any processes which 


were waiting on it are unblocked. 
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d. ked_wait_evct 
Function: ked_wait_evct(Integer: evct, Integer: value): Success Code 
Purpose: This function waits on a specified value for an evenctcount. 


Inputs: 
e Integer : evct — The eventcount we would like to wait on. 


e Integer : value — The value of the eventcount we would like to wait on 


Outputs: 

e Success Code — Indicated the result of the operation. Possible value inbluce: 
- SUCCEEDED - The operation completed successfully. 
- INVALID_EVCT - The specified eventcount identifier was not valid 
- FAILED —- The operation did not complete successfully 


Processing: 

{ | 
// Local variables 
Success_Code return_code; // success or error code 
Integer process id; //the current process 


return_code = SICCEEDED; 

// check for valid eventcount identifier 

if (evct < MIN_EVCT OR evct > MAX EVCT) { 
return_code = INVALID EVCT; } | 
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else if (KED[evct].status  IN_USE) { 
return_code = INVALID EVCT; } 

else { : 

// if the eventcount has not yet reached the requested value, 

// block the current process 

if (value > KED[evct].value) { 
process id = pm_get_current _process(); 
pm_change_process_status(process, BLOCKED); 
add <process id, value> pair to KED[evct].blocked; 


pm_switch_process(); 


} 
- 
-_- return return_code; 
j 
Effects: 


e If successful, the function returns when the specified eventcount has reached 


the specified value. 
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e. ksd_ create seq 
Function: ksd_create_seq(Integer: seq): Success Code 
Purpose: Allocates a new sequencer, initializes it and returns it to the caller. 
Inputs: None. 


Outputs: 
e Integer: seq — An index into the KSD which is the identifier for the new sequencer " 
e Success_Code — Indicates the result of the operation. Possible values include: 

- SUCCEEDED = The operation completed successfully 

- NONE AVAILABLE — No empty sequencer are available 

- FAILED — The operation was unable to complete successfully 


Processing: 


// Local variables 


Success_Code return_code; // success or error code 


return_code = SUCCEEDED; 
if (KSD_ Free Head == END OF LIST) { 
// set error code | 
return_code = NONE AVAILABLE; } 
// otherwise, allocate the sequencer 
else { 
seq = KSD Free Head; 
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KSDf[seq].value = INIT_VALUE: 
KSD_Free Head = KSD[seq].next; 
return_code = SUCCEEDED; 


Effects: 


e If successful, a new sequencer is allocated, initialized and returned to the caller. 
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f. ksd_destroy_seq 
Function: ksd_ destroy _seq(Integer: seq): Success Code 
Purpose: This function destroys a specified sequencer by returning it to the free list. 


Inputs: 


e Integer: seq — The identifier for the evenctounc we would like to delete 


Outputs: 

e Success Code — Indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully 
- INVALID SEQ- The specified sequencer 1s not valid 
- FAILED — The operation did not complete successfully 


Processing: 


// Local variables 


Success Code return_code; // success or error code 


return_code = SUCCEEDED; 

// check for valid sequencer identifier 

if (seq < MIN_SEQ OR seq > MAX_SEQ) { 
return_code = INVALID _ SEQ; } 

else if (KSD[seq].status # IN_USE) { 
return_code = FAILED; } 


// otherwise, deallocate the sequencer 
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else { 
KSD[seq].next = KSD_Free_Head; 
KSD_Free_Head = seq; 
return_code = SUCCEEDED; 

} 


return return_code; 


j 


Effects: 


e Ifsuccessful, the specified sequencer is added to the free list and is no longer 


available. 


103 





g. ksd_get_ticket 
Function: ksd_advance_seq(Integer: seq, Integer: ticket): Success_Code 
Purpose: This function advances a sequencer and returns the new value. 


Inputs: 


e Integer: seq — The sequencer to get a ticket from 


Outputs: 

e Success_Code — Indicated the result of the operation. Possible values include: 
- SUCCEEDED -— The operation completed successfully 
- INVALID SEQ - The specified sequencer was not valid 
- FAILED — The operation did not complete successfully. 


Processing: 


// Local variables 


Success_Code return_code; // success or error code 


return_code = SUCCEEDED; 

// check for valid sequencer identifier 

if (seq < MIN SEQ OR seq > MAX SEQ) { 
return_code = INVALID SEQ; } 

else if (KSD[seq].status + IN USE) { 
return_code = INVALID SEQ; } 


else { 
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// advance the sequencer 
KSD]seq].value = KSD[seq].value + 1; 
// set the return value 

ticket = KSD[seq].value; 

return_code = SUCCEEDED; 


} 
return return_code; 
} 


| Effects: 


e Ifsuccessful, the specified sequencer is advance and the new value is returned. 
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VII. PROCESS QUEUE MANAGER SPECIFICATION 


The process queue manager is responsible for maintaining the queues that service 


the various processes and TP tasks. The functions it provides include: 


e Create a queue 

e Delete a queue 

e Enqueue an item to a queue 

e Dequeue an item from a queue 


e Get work from a queue (without dequeing the item) 


Each queue is an MLS queue. The elements of the queue are the IDs of the 
segments that contain the transactions. The queues are organized based upon priority. 
Additionally, each queue also contains per access class pointers that permit per-access 


class searches of the queue. 


A request to get work from a queue contains a requested access class. The QTM 
will return a segment id and an access class. Ifa queue element exists with a higher 
priority than the next element at the requested access class, the high priority element will 


be returned along with its access class. If no elements exist at the requested access class, 


then the highest priority element on the queue along with its access class will be returned. 


The PQM essentially implements the chosen task scheduling policy. In this case, 
the chosen policy is to continue processing transactions of a given access class from a 
specific MLS queue until a higher priority transaction enters the queue or we exhaust all 
queue transactions of a given access class. When no items remain in the queue, it blocks 


on a wait call to a kernel eventcount which precipitates a process switch. 
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This specification implements all queues as arrays. This often creates inefficient 
insertion and search algorithms as well as leading to possible deadlock. A practical 
implementation would implement the priority queue using an efficient, dynamic 


datastructure (such as a heap). 


. PROCESS QUEUE MANAGER CONSTANTS 


> 


a. MAX MLS QUES — The maximum number of MLS queues the system can handle 
b. MAX QUE SIZE — The maximum size of an MLS queue 

c. MAX ACCESS CLASSES — The maximum number of access classes in the system 
d. MIN MQUE - The minimum value used to index the list of MLS queues 


e. MIN QUE - The minimum value used to index the queue itself 


B. PROCESS QUEUE MANAGER DATABASES 


a. Process Queue Database (PQD) 
Queue elements have the following format: 


struct Queue Entry { 


Access_Class: access; // access class of this element 

Integer: priority; // priority of this element 

Segment: seg id; // segment id of the transaction ~ 

Integer: next _pri; // next element in the priority queue 

Integer: prev_pri; // previous element in the priority queue 
Integer: next_access; // next item in the access class queue 

Integer: prev_access; // previous item in the access class queue 


108 





The process queue database stores information about each MLS process queue. 
Each entry in the process queue database has the following format 


struct Process_Queue Entry { 
Kernel_Evct: eventcount; | // the eventcount associated with this queue 
Queue Entry: mls_queue[1..MAX QUE_ SIZE]; // the queue elements 
// pointers to elements within the queue, creates our per access class queues 
// we store both heads and tails. An access class indexes into this array 
Integer: que_heads[1.MAX ACCESS CLASSES}; 
Integer: que_tails[0. MAX ACCESS CLASSES]; 


// pointers to the queue head and tail 


Integer: pri head; // head of the mary queue 

Integer: pri_ tail; // tail of the queue 

Integer: free_head; if head of the free element within the queue 
Integer: hold_head; 7 // head of queue 


Integer: hold_tail; 
// used to chain together free entries in the PQD 
Integer: next_free; 


Status_Code: que_status; _// holds the status of the queue 


The process queue database 


struct Process_Queue_Entry PQD[MAX MLS QUES]; 
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. PROCESS QUEUE MANAGER MODULE VARIABLES 


. PQD_FIRST_FREE — index into the PQD of the first free entry. This would in turn 


be chained to the other free entries. 


. PROCESS QUEUE MANAGER FUNCTIONS 


. pqm create 


Function: pqm_create(CMLS_ Queue _ID: mls_q): Success_Code 


Purpose: This function sets up a new MLS queue and returns an index into the PQD 


which identifies the new queue. 
Inputs: None. 


Outputs: 
e MLS Queue ID: mls_q — the index into the PQD which identifies the new 
queue 
e Success Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - the operation completed successfully 
- NO RESOURCES - the operation failed due to an inability to allocate 


necessary resources 


Processing: 
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// Local variable 


Success Code: return_code; // holds the return code 
Kernel EVCT: k_evet; // kernel eventcount for new queue 
Integer: xs: // loop index variable 


return_code = SUCCEEDED; 

// check for a free entry in the PQD 

if (PQD_FIRST_ FREE == EMPTY LIST) { 
// if none, set error code 
return_code = NO_ RESOURCES; } 

// otherwise, get a kernel eventcount for this queue 

else if icem oreaereven != SUCCEEDED) { 
// if we couldn’t create a kernel eventcount, set error 
return_code = NO_RESOURCES; } | 

// otherwise, set up the queue 

else { | 
mis q=PQD_ FIRST FREE; 
// advance the free list | 
PQD_FIRST_FREE = PQD[PQD_FIRST_FREE].next_free; 
// initialize queue attributes | 
PQD[mls_q].eventcount = k_evct; 

// initialize each element of the queue (create the free list) 

// the field used to point to the next item in the priority list 

// “pri_next’ is used for the free list link as well 
for (ix = 1; ix <= MAX _QUE SIZE; ix =ix + 1) { 

PQD[mls_q].mls_queue[ix].next_pri =ix + 1; } 

// initialize the access class pointers (all empty) 
for (ix = 1; ix <= MAX ACCESS CLASSES; ix = ix + 1) { 
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.PQD[mls_q].que_heads[ix] = EMPTY QUE; 
PQD[mls_q].que_tails[ix] = EMPTY QUE; 
} 
// initialize other pointers 
PQD([mls_q].pri_head = EMPTY QUE; 
PQD[mls_q].pri_tail = EMPTY_QUE; 
PQD[mls_q].free_ head = EMPTY QUE; 
PQD[mls_q].hold head = EMPTY QUE; 
PQD[mls_q].hold_tail = EMPTY QUE; 
PQD[mls g].que status = IN USE; | 
// we’re done 


} 


return return_code; 


Effects: 
e If successful, a new MLS queue will be setup with all its elements on marked 
free. The calling process will be returned the index into the PQD 


corresponding to the new queue. 
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b. pqm_ delete 
Function: pqm_delete(MLS_Queue ID: mls_q): Success Code 


Purpose: This function removes a queue from the PQD. This function will only work 
if the queue is empty. It is the responsibility of the calling program to remove all 


items from the queue prior to attempting to delete it. 


Inputs: 
e MLS _Queue_ID: mls_q—the PQD index identifying the queue to delete. 


Outputs: 

e Success_Code — indicated the result of the operation. Possible value include: 
- SUCCEEDED - the operation completed successfully 
- NOT_EMPTY — the queue in question is not empty. 
- INVALID QUEUE - the queue referenced is not currently in use 


Processing: 


// Local variables 


Success Code: return_code; _ // holds the return code 


return_code = SUCCEEDED; 

// Check for a valid MLS queue id 

if ((mls_q < MIN_MQUE) OR (mls_q>MAX MLS QUES)) { 
//if invalid, set errorcode _ 
return_code = INVALID QUEUE; } 
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// check that the referenced queue is in use 

else 1f (PQD[mls_q].queue_status != IN_USE) { 
// if invalid, set error code 
return_code = INVALID QUEUE; } 

// make sure the queue is empty 

else if (PQD[mls_q].pri_head != EMPTY QUE) { 
// if not empty, set error code 
return_code = NOT_EMPTY; } 


// otherwise, go ahead an deallocate the queue index | 


else { 
PQD[mls_q].queue_status = FREE; 
PQD[mls_q].next_free = PQD FIRST FREE; 
PQD FIRST FREE = nls q; | 
// we’re done 
yO | 
return return_code; 
} 
Effects: 


e If successful, the entry in the PQD indicated is returned to the list of free PQD 


entires. 
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. pqm_enque 


Function: pqm_enque(MLS Queue ID:mls_q, Segment: seg_ id, Integer: priority): 


Success Code 
Purpose: This function adds an item to a MLS queue. 


Inputs: . 
ie MLS Queue ID: mls_q—the MLS queue to which we want to add an item 
6 Segment: seg 1d — the identifier for the segment we would like to add to the 
queue, this segment contains the transaction 


e Integer: priority — the priority of the 1tem to be added 


Outputs: 
e Success_Code — indicates the success of the operation. Possible values 
include: | 
- SUCCEEDED -~ the operation completed successfully | 
- NO RESOURCES —a resource needed to complete the operation was 
unavailable 


- INVALID ARG — an argument provided was not valid 


Processing | 
{ 
// Local variable 
Success_Code return_code; // the return code 
Access Class: access; // the access class of the segment 
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Integer: que_item; // the new item in the queue 


Integer: 1X; /! loop index variable 
Integer prev_item; // holds queue item index 


Boolean: done = FALSE; // completion flag 


return_code = SUCCEEDED; 

// check for a valid MLS que 

if ((mls_q< MIN MQUE) OR (mls_g>MAX MLS QUES)) { 
/f set error code 
return_code = INVALID_ARG; } 

else if (PQD[mls_q].queue_status != IN USE) { 
// set error code 
return_code = INVALID_ARG; } 

// check for a valid segment 

else if (mm_get_access(seg_ id, access) '= SUCCEEDED) { 
// set error code 
return_code = INVALID ARG; } 

// otherwise, add the item 

else { 

// check for free slot in the queue 

if PQD[mls_q].free_ head == EMPTY LIST { 
// if none avail, set error code 
return_code = NO_ RESOURCES; } 

} 

// otherwise, add the item 

else { 
que_item = PQD[mls_q].free_head; 
PQD[mls_q].free_head = 
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PQD{[mls_q].queue[PQD[mls_q].free_head].next_pri; 
PQD[mls_q].queue[que_item].priority = priority; 
PQD[mls_q].queue[que_item].access = access: 
PQD[mls_q].queue[que_item].seg id= seg id; 
// First, insert into the priority queue 
ix = PQD[mls_q].pri_tail; 
while ((ix != EMPTY_END) AND (done != TRUE)) { 
// check if we are in the right priority spot 
if (PQD[mls_q].queue[ix].priority < priority) { 
| // if not, check the next item 
ix = PQD[mls_q].queue[ix].prev_pri 5} 
// we are at the right spot to insert the item 
else { 
done = TRUE: 


j 


// Now, we actually insert the item in the priority queue 

// check to see if we reached the end of the queue 

if (ix == EMPTY QUEUE) { 
PQD[mls_q].queue[que_item].next_pri = 

PQD[mls_q].que_head; 

PQD[mls_q].queue[que_item].prev_pri = EMPTY_QUE; 
PQD[mls_q].pri_head = que_item; | 
// check for an empty queue 
if (PQD[mls_q].pri_tail = EMPTY QUEUE) { 

- PQD{[mls_q].pri_tail = que_item; 
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// otherwise, we stopped somewhere in the middle of the queue 
else { 


prev_item = PQD[mls_q].queue[ix].prev_pri; 


// see if the item we are pointing to has an item before it 


if (prev_item != EMPTY QUE) { 
// if yes, set its forward link 
PQD{[mls_q].queue[prev_item].pri_next = 
que item; 
} 
// insert the new item into the priority queue 
PQD[mls_q].queue[i1x].prev_pri = que_item; 
PQD[mls_q].queue[que_item].next_pri = ix; 
PQD[mls_q].queue[que_item].prev_pri = prev_item; 
} 
// Second, search the priority queue 
ix = PQD[mls_q].que_tails[access]; 
while ((ix != EMPTY_END) AND (done != TRUE)) { 
// check if we are in the right priority spot 
if (PQD[mls_q].queue[ix].priority < priority) { 
// if not, check the next 1tem 
ix = PQD[mls_q].queue[ix].prev_access ; } 
// we are at the right spot to insert the item 
else { 
done = TRUE; 


} 


// Now, we'actually insert the item in the access class 


// queue 
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/| Check to see if we reached the end of the queue 
if (Ix == EMPTY QUEUE) { 
PQD{[mls_q].queue[que_item].next_access = 
PQD[mls_q].que_head; | 
PQD[mls_q].queue[que_item].prev_access = EMPTY QUE; 
PQD[mls_q].pri_head = que_item; 
// check for an empty queue 
if (PQD[mis_q].pri_tail = EMPTY QUEUE) { 
— PQD[mls_q].pri_tail = que_item; 
a | 
} 
else { 
prev_item = PQD[mls_q].queue[ix].prev_access; 
// see if the item we are pointing to has an item before it 
if (prev_item != EMPTY QUE) { 
// if yes, set its forward link — 
PQD[mls_q].queue[prev_item].pri_access = que_item; 
: 
// insert the new item into the priority queue 
PQD{[mls_q].queue[ix].prev_pri = que_item; | 
PQD[mls_q].queue[que_item].next_access =ix; — 


PQD[mls_q].queue[que_item].prev_access = prev_item; 


j 


return return_code; 
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Effects: 
* If successful, this function inserts a new item into the queue. Both priority links 
and access class links are updated. The item is inserted into the queues based 


upon priority. 

. pqm_deque 

Function: namdequatMs Oude dDaileg. Segment: seg_ id): Siccese Code: 
Purpose: This function removes an item from a specified MLS queue. 


Inputs: 
-@ MLS Queue ID: mls _q—the MLS queue from which to dequeue the item. 


_e@ Segment: seg id —the segment to remove from the queue. 


Outputs: 
e Success_Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED - the operation was successful. - 
- INVALID QUE -the MLS queue specified was not valid 
- ITEM_NOT_FOUND - the specified item was not found on the queue 


Processing: 

{ 
// Local variables 
Success Code return_code; // stores the return code 
Integer 1X; // loop index variable 


120 








Access_Class access; // the item’s access class 
Boolean done; // loop termination flag 
Integer item; _ // stores temporary index into queue 


return_code = SUCCEEDED; | 
if ((mls_q <0) OR (mls_q>MAX_MLS_QUES)) { 
// set error code 
return_code = INVALID QUE; } 
else if (PQD[mls_q].queue_status != IN USE) { 
| // set error code 
return_code = INVALID QUE; } 
// otherwise, search for the item 
else { 
// check the hold queue first. 
ix = PQD[mls_q].hold_head; 
done = FALSE; | 
while (ix != EMPTY_QUE) { 
if (PQD[mls_q].queue[ix].seg_id == seg id) { 


done=TRUE; 
j 
else { | 
ix = PQD{[mls_q].queue[ix].next_pri; 


} 


// check if we found the item 
if (ix != EMPTY QUE) { - 
// first, remove from priority queue | 


item = PQD{mls_q].queue[ix].prev _pri; 
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// check for beginning of queue 
if (item == EMPTY_QUE) { 
PQD[mls_q].hold_head = PQD[mls_q].queue[ix].next_pri; 


} 
else { 
PQD[mls_q].queue[item].next_pri = 
PQD[mls_q].queue[ix].next_pri; 
} 


i check for end of queue 
item = PQD[mls_q].queue[ix].next_pri; 
if (item == EMPTY QUE) { 
PQD[mls_q].hold_tail = PQD[mls_q].queue[ix].prev_pri; 


} 
else { 
PQD{[mls_q].queue[item].prev_pri = 
PQD[mls_q].queue[ix].prev pri: | 
, 


} 


// if we found the item, skip searching the priority que 
if (done != TRUE) { 
while (ix != EMPTY QUE) { 
if (PQD[mls_q].queue[ix].seg id == seg id) { 
done=TRUE; 


else { 


ix = PQD[mls_q].queue[ix].next_pri; 
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// check 1f we found the item 
if Gx = EMPTY QUE) {© 
// first, remove from the priority queue 
item = PQD[mls_q].queue[ix].prev _ pri; 
// check for beginning of queue 
if (item == EMPTY .QUE) { 
PQD[mls_q]-pri_ head = 
PQD{[mls_q].queue[ix].next_pri; 
} 
else { 
PQD[mls_q] -queue[item].next_pri = 
PQD{mls_q].queue[ix].next _pri; 


} 
// check for end of queue 
item = PQD[mls_q].queue[ix].next_pri; 
if (item == EMPTY QUE) { 
PQD[mis_q].pri_tail = PQD[mls_q].queue[ix].prev_pri; | 
else { 
PQD{[mls_q].queue[item].prev_pri = 
PQD|[mls_q].queue[ix].prev._pri; 
| 
} 


j 


// if we found the item, update the access class links 
if (done == TRUE) { 
item = PQD[mls_q].queue[ix].prev_access; 


// check for beginning of queue 
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if (item == EMPTY QUE) { 
PQD[mls_q].que_heads[access] = 
PQD{[mls_q].queue[1x].next_access;} 
else { 
PQD[mls_q].queue[item].next_access = 
PQD[mls_q].queue[ix]}.next_access; 
} 
// check for end of queue | 
item = PQD[mls_q].queue[ix].next_access; 
if (item == EMPTY QUE) { 
PQD[mls_q].que_tails[access] = 


PQD[mls_q].queue[ix].prev_access; 


} 
else { 
-PQD[mls_q].queue[item].prev_access = 
PQD[mls_q].queue[ix].prev_access; 
} | 
// add removed item to free list 
_ PQD{[mls_q].queue[ix].next_pri= PQD[mls_q].free_head; 
PQD[mls_q].free_head = 1x; 
} , 
else { 
return_code = ITEM_NOT_FOUND; 
} 


return return_code; 
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Effects: 


e If successful, the queue element which contains the specified segment ID is 


removed from the specified MLS queue. 








e. pqm_ get _work 


Function: pqm_get_work(MLS Queue ID: mls_q, Access Class: access, Segment: 


seg id): Success Code 


Purpose: | 
This function returns the segment ID of an item from the specified MLS queue. The 
access class passed in might also be changed if the returned item is of a different 


access Class (due to high priority or no items of the requested access class). 


Inputs: . | 

e MLS Queue ID: mls_gq—the MLS queue from which we would like to get 
work | 

e Access Class: access — the requested access class, if work exists at this access 
class without any higher priority elements, itis returned. This input is also an 


output as it might be changed by the function 


Outputs: 
e Access Class: access — contains the access class of the returned item 
e Segment: seg_id—contains the segment ID of the return item, if any 
- Success Code — indicates the result of the operation. Possible values 
include: 
- SUCCEEDED - the operation completed successfully 
- INVALID QUE ~— the specified MLS queue is invalid 


Processing: 
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// Local variables 


Success Code return_code; // stores the return code 
Access_Class return_access; // the access class of return item 
Integer item, pri_item, access item; // temporary queue indices 


Integer ticket; // holds the ticket for the queue 


return_code = SUCCEEDED; 
// check for a valid MLS que 
if (Gmls_q < MIN MQUE) OR (mls_q >MAX MLS QUES)) { 
_ // set error code | | : 
return_code = INVALID QUE; } 
else if (PQD[mls_gq].queue_status != IN USE) { 
// set error code 
return code = INVALID QUE; } 
// otherwise, get an item 
else { | 
// block if there are no items on the queue 
kem get ticket(PQD [mls _q].evct,ticket); 
kem_wait(PQD[mls_q].evct,ticket); 
if (PQD[mls_q].que_heads[access] == EMPTY QUE) { 
item = PQD[mls_q].pri_head;} 
else { 
pri_item = PQD[mls_q].pri_head; 
access item = PQD[mls_q].que_heads[access]; 
if (PQD[mls_q].queue[pri_item]-priority > 
PQD[mls_q].queue[access_item].priority) { 


item = pri_item; 
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else f 


item = access_item; 


} 


access = PQD[mls_q].queue[item].access; 
// remove item from priority and access class links 
PQD[mls_q].pri_head = PQD[mls’ q].queue[item].next_pri; 
if (PQD[mls_q].pri_tail = item) { 

PQD[mls_q].pri_tail= EMPTY QUE; 


} 
else {° 
pri_prev = PQD[mls_q].queue[item].prev_pri; 
PQD[mls_q].queue[pri_prev].next_pri = EMPTY QUE; 
} 


PQD[mls_q].que_heads[access] = 
PQD{mls_q].queuefitem].next access: 
if (PQD[mls_q].que_tails[access] = item) { 
~ PQD[mls_q].que_tails[access] = EMPTY QUE; 
| 
else { 
access_prev = PQD[mls_q].queue[item].prev_access; 
PQD[mls_q].queue[pri _prev].next_ access = EMPTY QUE; 
// add item to hold queue, 
pri_ tail = PQD[mls_q].hold_tail; 
PQD[mls_q].hold_tail = item; 
PQD[mls_q].queue[item].prev_pri= EMPTY QUE; 
if (pri_tail != EMPTY QUE) { 
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PQD[mls_q].queue[item].next_pri = pri_tail; 
PQDjmls_q].queue[pri_tail].prev_pri = item; 


} 
seg_id = PQD[mls_q].queue[item].seg_ id; 
. 
return return_code; 
j 
Effects: 


-e If successful, this call will return a segment ID and an access class. The returned 
item is the highest priority item in the queue or the requested access class if that is 


the highest priority item in the queue. The caller should check the returned access _ 


class. 
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VI. TASK MANAGER SPECIFICATION 


The Task Manager is responsible for manager the several single level tasks within 


the process. It implements the following functions: 


e Createa me task 
- @ Destroy a task 
e Switch a task 
e Get work for a task 


e Add memory to a task address space 


The Task Manager maintains a database of the tasks being managed and the 
access class of those tasks. Tasks request new transactions from the Task Manager. The 
Task Manager interfaces with the appropriate MLS queue to retrieve the transactions. If 
no transactions of the requested access class are available, the current task is suspended 


and a task for which a transaction does exist is scheduled. _ 


A. TASK MANAGER CONSTANTS 


The task database is indexed based upon access class. Therefore, the possible access 
Classes in the system would be converted to an ordered list, indexed starting at 1 for the 
first access class and going to MAX ACCESS CLASS for the last access class inthe . 
ordered list. The index assigned to each access class does not denote any relationship or 


precedence between the access classes, it is merely used for indexing. 


a. MAX ACCESS CLASS — The maximum number of tasks the Task Manager can 
- handle 











B. TASK MANAGER DATABASES 


a. Task Database 
The task database stores information about the various tasks being managed by the 
Task Manager. The task database 1s indexed by access class, therefore, there can be 
only one task per access class. 


Each entry in the task database has the following format 


struct Task Entry { 


LDT_ Database Entry : ldt_id; // the LDT image for this task 
Task Status : status; | // the status of this task 
Access_ Class: access; // the access class of this task 
Task_Context: context; // the saved task context 
Task_Entry : next; // the next task in the list 
Task_Entry : prev; _ // the previous task in the list 


The database is an array of task entries 


Array of Task_Entry : Task_Database[1..MAX ACCESS CLASS]; 


C. TASK MANAGER VARIABLES 


a. Current_Task — the access class (index) of the current task (this uniquely identifies 


the current task) 
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b. MLS_Que — The MLS queue associated with this process (all tasks) 
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D. TASK MANAGER FUNCTIONS 


. a. 


tm_create_task 
Function: tm_create_task(Access_Class: access): Success Code 


Purpose: This function initializes a new TP task to process transactions of a given 


access class. 


Inputs: 


e Access_Class: access — The access class at which to create the new task 


Outputs: 
e Success_Code — indicates the result of the operation. Possible values include: 
- SUCCEEDED — The operation. completed successfully 
- NO LDT SPACE -— The function was unable to allocate an LDT 
; TASK_IN_USE — A task of the given access class already exists 
- INVALID_ACCESS_ CLASS — The specified access class is not valid 
- FAILED — The operation did not complete successfully 


Processing: 

{ 
// Local variables | 
Success Code return_code; // success of error code 
LDT_Database Entry new_ldt; // new Idt for task 
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return_code = SUCCEEDED; 
// default case is failure 
return_code = FAILED; 
// Ensure we have a valid access class 
if (valid_access_class(access) TRUE) { 
// set error code 
return_code = INVALID ACCESS CLASS; 
H Ensure we don’t already have a task at the given access class 
if (Task_Database[access] # FREE) { 
// set error code 
return_code = TASK_IN_USE; } 
// ensure we can allocate a new LDT for the task 
else if (Idt_create_Idt(access, new _ldt) # SUCCEEDED) { 
| // set error code 
return_code = NO_LDT SPACE; } 
/ otherwise, initialize the task 
else { 
// assign the new LDT 
Task_Database[access].ldt_id = new ldt: 
// mark this task as in use 
Task Database[access].status = READY; 


//**** Additional setup of the address space and context would 


// **** g0 here. Such things as settting up the code segment, initial 


// **** T DT, initial selectors, initial program counter, etc... 
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return return_code; 


Effects: 


e Ifsuccessful, a new task at the specified access is created and initialized. The 


identifier associated with the new task will be the access at which it was created. 


136 





b. tm_destroy_task 
Function: tm_destroy_task(Access_Class: access): Success Code 
Purpose: This function destroys the task at a given access class. 


| Inputs: 


e Access_Class: access — The identifier (access class) for the task to destroy 


Outputs: 
e Success_Code — Indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully 
- INVALID ACCESS CLASS - The specified access class is not valid 
- NO_TASK - There is no task at the specified access class 
- FAILED— The operation did not complete successfully 


Processing: 


// Local variables 


Success_Code return_code; // success or error code 


return_code = SUCCEEDED; 
// Ensure we have a valid access class 


if (valid_access_class(access) # TRUE) { 


// set error code 
return_code = INVALID ACCESS CLASS; 


// Ensure we don’t already have a task at the given access class 








if (Task_Database[access].status == FREE) { 
// set error code 
return_code = NO_TASK; } 
// otherwise, remove the task 
else { 
// **** Teallocation of task memory and resources should occur 
// **** here. The code segment and other segment held might have 
// **** to be deallocated. Once this is done, we can deallocate 


// **** the LDT 


Idt_destroy_lde(Task_Database[access].]dt_id); 
// mark this task as free 

Task _Database[access].status = FREE; 
return_code = SUCCEEDED; 


} 

return return_code; 
} 
Effects: 


e Ifsuccessful, the task of the specified atcess class will have its resources 


allocated and marked as free. 
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c. tm_switch_task 
Function: tm_switch_task(Access_Class: access): Success Code 
Purpose: This function switches to the task corresponding the specified access class 


Inputs: 
e Access_Class: access — The identifier (access class) of the task we would like to 


- switch to’ 


Outputs: 
-@ Success Code — Indicates the result of the operation. Possible values include: 
- SUCCEEDED - The operation completed successfully 
- INVALID _ACCESS CLASS — The specified access class does not exit 
- NO TASK -— There is no task of the specified access class 
- FAILED — The operation did not complete successfully 


Processing: 


// Local variables 


Success Code return_code; // success or error code 


// default case is failure 
return_code = FAILED; 
// Ensure we have a valid access class 


if (valid_access_class(access) # TRUE) { 


// set error code 








return_code = INVALID ACCESS CLASS; 
// Ensure we don’t already have a task at the given access class 
if (Task_Database[access].status == FREE) { 

'// set error code 

return_code = NO_TASK; } 

// otherwise, make the switch 
else { 

// save the current task 

save_task_context(Task_Database[Current_Task].context); 

Task Database[Current_Task].status = SUSPENDED; 

// restore the context of the new task 

restore _task_context(Task_Database[access].context); 

// switch the LDT 

Idt_switch Idt(Task_Database[access].Idt_id); 


// **** Other steps as necessary to save and restore the state 


// **** go here. 


} 


return return_code; 


Effects: | 
e If successful, the current task will have its context saved and the new task (of the 


specified access class) will have its context restores and its LDT loaded. 
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| IX. CONCLUSION 
There are applications within the military that would benefit from the existence of 
an MLS TP system. A preliminary three-tier architecture that proudes a rudimentary TP 
system based upon the abstractions of task, process and kernel has been presented. This 
architecture avoids the normally heavy cost of a context switch in an MLS system by 
leveraging the sécurity features of the Intel Pentium microprocessors. By effectively 
using the privilege level and descriptor table mechanism of these processors, the required 
processing to switch between access classes can be significantly reduced. 
| What has been presented here is the preliminary architecture for such a system. 


Implementation, using the presented specification for scaffolding, can be the subject of 


future work. The addition of a file-system, memory management (to include paging), and 


device management would greatly add to the functionality of the system. 
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